Coder Legion - Recent posts tagged saas

StripeFlow

Thu, 29 Oct 2026 00:07:22 +0000

StripeFlow Analytics is a self-hosted analytics platform designed to help SaaS businesses turn Stripe data into actionable insights through revenue tracking, churn analysis, customer lifetime value, and payout forecasting.

The project is currently pre-revenue with no customers, presenting a great opportunity for an entrepreneur, SaaS company, or established analytics provider to acquire a ready-to-develop product, establish its market presence, and build a customer base from the ground up.

StripeFlow Analytics offers a compelling starting point for someone looking to enter or expand within the SaaS analytics market.

UnifyAPI Integrations

Thu, 29 Oct 2026 00:02:57 +0000

UnifyAPI Integrations helps developers and SaaS builders simplify repetitive API integration work with reusable code for authentication, retries, and webhook handling.

Currently pre-revenue with no customers, it presents a great opportunity for an entrepreneur or software company to establish its market presence, build a customer base, and monetize a solution addressing a common developer pain point.

B2B SaaS MVP Example

Wed, 28 Oct 2026 14:38:30 +0000

Defining a minimum viable product for business software often stalls when teams try to build every feature requested by early prospects. Quick solution: Focus your B2B SaaS MVP example on a single end-to-end user workflow that delivers immediate value, backed by a strict scope worksheet and foundational security.

mvp_configuration:
  target_workflow: "csv_import_and_validation"
  core_persona: "finance_manager"
  excluded_features:
    - "real_time_collaboration"
    - "advanced_rbac_roles"
  security_baseline:
    - "tls_encryption_in_transit"
    - "row_level_access_checks"

When designing an MVP, technical founders and product managers face a delicate operational balance. Building too little leaves users unable to complete their primary tasks, while building too much delays learning and burns capital. As outlined in guidelines on minimum viable product development, the goal is to validate assumptions with the least amount of effort. In enterprise contexts, this requires looking beyond simple landing page tests to ensure the core software actually solves a painful business workflow. Teams frequently make the mistake of treating software prototypes like consumer applications, ignoring the strict integration, compliance, and multi-tenant isolation requirements that define enterprise software adoption.

Understanding the Core B2B SaaS MVP Workflow

A successful B2B MVP centers on a single persona executing a high-value task. Unlike consumer apps that rely on broad viral loops, business software must prove tangible efficiency or cost reduction for a specific role. When evaluating product strategy during early project definition, teams often benefit from external frameworks such as those found in the Azure Well-Architected Framework, which emphasizes security, reliability, and cost optimization from the outset. Even in an early prototype, ignoring basic operational pillars creates technical debt that hinders later scaling. For a deeper look at evaluation criteria, How To Evaluate A Technical Product provides a structured lens for assessing product viability before writing code.

To establish a viable workflow, product teams must isolate the single operational bottleneck causing the most friction for their target buyer. For instance, if finance managers spend hours manually reconciling disparate CSV spreadsheets every week, the MVP should ingest, parse, and validate those exact files automatically. It should not attempt to generate predictive forecasts, manage company-wide payroll, or provide custom workflow builders. By restricting the software scope to this single acute problem, engineering teams can ship within weeks rather than months, allowing early design partners to test the core value proposition directly in their staging or production environments.

MVP Scope Worksheet and Illustrative Sample

To prevent scope creep, use a structured worksheet that separates essential core requirements from future enhancements. Below is a sample worksheet illustrating how to define boundaries for a fictional analytics import tool.

Project Component	Included in MVP	Excluded from MVP	Rationale
Data Ingestion	CSV file upload	Direct API integrations	CSV covers eighty percent of initial user data sources without custom connectors.
User Authentication	Single tenant email and password	Enterprise SSO (SAML/OIDC)	SSO can be deferred until the first three enterprise design partners request it.
Reporting	Static weekly summary email	Custom drag and drop report builder	Static reports validate the core value proposition faster than complex UI work.

Using a worksheet like the one above forces cross-functional stakeholders to agree on what is truly necessary for day one adoption. When product managers, lead engineers, and sales leads review these boundaries together, they can negotiate features based on engineering cost and user feedback rather than subjective preference. This artifact serves as a single source of truth during the sprint planning phase, preventing informal hallway conversations from quietly expanding the software footprint.

Trade-Offs and Failure Modes

Every MVP strategy involves compromises. Recognizing these failure modes early helps teams pivot before writing unmaintainable code.

Pattern	When to Use It	Trade-Off or Failure Mode	Recommendation
Wizard of Oz MVP	Validating complex backend logic with manual fulfillment	High manual operational overhead; users may expect instant automation.	Use only for high-value workflows where manual steps are invisible to the end user.
Single Workflow MVP	When target users have one overwhelming bottleneck	Risk of ignoring adjacent workflows needed for broader team adoption.	Ensure the chosen workflow solves an acute pain point that justifies installation.
Feature Subset MVP	Stripping down an enterprise suite to basic functions	May appear too basic compared to mature competitors, leading to low engagement.	Position the product clearly as an early preview focused on specific use cases.

Failing to anticipate these trade-offs often leads to premature abandonment by early users. For example, if a team deploys a Wizard of Oz pattern where data processing is secretly performed by humans behind the scenes, a sudden influx of sign-ups can overwhelm the operational team, causing severe delays that erode user trust. Conversely, building a feature subset that is too sparse can cause prospects to dismiss the tool as a toy. Maintaining transparency with design partners about the software boundary helps align expectations and preserves goodwill.

Verification and Execution Checklist

Before launching your MVP to design partners, run through these verification checks to ensure operational readiness.

Confirm the core workflow can be completed end-to-end by a test user without manual intervention.
Verify that data encryption is active both in transit and at rest to meet basic enterprise compliance.
Establish telemetry to track whether users successfully reach the completion state of the primary workflow.
Document explicit exclusions so stakeholders understand what is deliberately left out of the initial release.

Should a Failed Upload Clear the Form?

Wed, 28 Oct 2026 10:23:21 +0000

Cover: original AI-generated concept illustration with a fictional interface, not a working product screenshot.

Imagine filling in a project name, description and photo captions, then having the upload fail. Should the whole form reset, or should only the failed step need attention?

My starting point would be to keep completed fields, identify which file failed and explain whether the project itself was saved. “Upload failed” should not leave someone guessing whether they need to recreate everything.

I would also distinguish retrying the same file from choosing a replacement. If the original request's outcome is unknown, the app should check its status before offering a retry that might create a duplicate.

Keeping work has boundaries: a shared device may make persistent local drafts inappropriate, and sensitive content should not be retained indefinitely just for convenience.

Where would you draw the line between preserving a form in the current session and saving a recoverable draft? What should the interface tell users before they leave?

I automated the hardest parts of Amazon SES, so you can send from your own AWS account in two minute

Wed, 28 Oct 2026 06:00:57 +0000

Amazon SES is the most cost-effective way to send transactional email. But a production setup
takes real work: IAM, the sandbox, bounce and complaint handling, logs, and watching your
reputation. I built SendFleet to do that work inside your own AWS account.

What it does

One-click connection. A CloudFormation template creates a scoped IAM role. Paste its ARN and
you are connected. No AWS keys are ever shared.
Finds your sending region. Production access is per region, so SendFleet checks them all and
picks the one that can send. If none can, it requests production access for you.
Tracking and webhooks. It sets up the configuration set and SNS topic in your account, keeps
them healthy, and turns events into an email log and signed webhooks.
Reputation protection. It pauses sending before your bounce or complaint rate reaches the
levels where AWS starts reviewing accounts.
Cost controls. You choose which SES events your account publishes, and set a monthly cap.
Transparency. Every change SendFleet makes in your account is listed in the dashboard.

How it is built

A Rust API for sending (POST /v1/send).
A Django dashboard.
Python Lambdas in a separate AWS account: a relay that assumes your role to send, a control
plane for setup and self-healing, and an event worker.
Postgres on Neon. Message bodies never reach the database.

Pricing

Free for 3,000 emails a month. $5 a month with 20,000 emails included, then $0.10 per 1,000. You
pay AWS for SES directly.

Try it at https://sendfleet.net. I'm keen to hear what would make you trust a tool like this with
your AWS account.

What Does an Empty Dashboard Mean?

Tue, 27 Oct 2026 10:47:59 +0000

Original AI-generated concept illustration, not a working product screenshot.

An empty dashboard can mean three different things: nobody has added a record, filters exclude the existing records, or the data request failed. Showing “No results” for all three leaves the user guessing.

My default would be one short explanation and one relevant next step: create a record, clear the filters, or retry the request. I would avoid a creation prompt when the app has not confirmed whether records already exist.

There is a trade-off, though. Explaining every possible cause can make a simple screen noisy, and some users may not have permission to see why data is unavailable.

What is the minimum context you would show in an empty state, and when would you offer more than one action?

When Should Delete Offer Undo?

Mon, 26 Oct 2026 10:29:03 +0000

Undo is useful only when it genuinely restores what the user lost. A confirmation dialog is useful only when it explains the consequence—not just “Are you sure?”

Consider a hypothetical media app where someone deletes a set of property photos. My starting point would be:

Reversible removal: move files to trash, show a clear Undo action, and keep a discoverable recovery route after the toast disappears.
Permanent or bulk deletion: show the affected names or count, what cannot be restored, and whether shared access will be affected before proceeding.
Partial failure: report which files changed instead of claiming the entire operation succeeded.

The tricky case is shared assets: restoring a file may not reverse notifications or other effects that already happened.

W3C’s error-prevention guidance provides a useful reference for certain important submissions and changes to user-controllable stored data: reversal, checking, or confirmation. It does not mean adding a confirmation dialog to every routine edit.

Where do you draw the line between Undo, confirmation, and both? Would your answer change for one recoverable file versus a folder shared with a team?

Cover: original AI-generated conceptual illustration. The interfaces and recovery period shown are fictional, not a product demonstration.

When Is a Progress Bar Misleading?

Sun, 25 Oct 2026 10:26:33 +0000

A progress bar should tell users what has been measured, not just reassure them that something is happening.

Consider a hypothetical photo-processing tool: upload progress is measurable in bytes, but the next step might wait in a queue or take a different amount of time for each image. A bar that reaches 99% and then stalls can turn a useful signal into false precision.

My proposed default would be:

Use a percentage for work with a meaningful, known total.
Use explicit stages such as Queued → Processing → Ready when completion time is uncertain.
Show completed-file counts for batches, while making clear that files may take different amounts of time.
Keep failure and cancellation states separate from progress.

There is an accessibility detail too: status updates should be available to assistive technology without moving keyboard focus. W3C's guidance on status messages also warns against making updates too chatty; announcing every tick is not necessarily helpful.

Where would you draw the line between a useful estimate and false precision? Would you show stage labels, an estimated range, or a percentage when processing time varies?

Cover: original AI-generated concept illustration of fictional processing interfaces, not a product screenshot or performance result.

When Should a Client Preview Link Expire?

Sat, 24 Oct 2026 10:39:25 +0000

Cover: original AI-generated concept illustration, not a screenshot of a working product. The durations are discussion examples, not recommendations.

A photographer shares an unpublished property-photo preview on Friday. The agent opens it on Monday, after the link has expired. A longer lifetime would reduce friction, but the link could also be forwarded.

For a small client-review tool, which approach would you choose?

A short-lived direct link, with a clear way to request a new one.
A longer review window with an explicit expiry notice.
An authenticated review page that issues short-lived asset links after checking access.

AWS documents that S3 presigned URLs act as bearer tokens and can expire earlier when their underlying credentials expire: official S3 guidance. That distinction matters when the UI promises a review window. Expiry also cannot recall a file someone has already downloaded.

What should the recipient see after expiry, and how would you make recovery easy without silently extending access? I would favour a clear expiry message and an explicit renewal path, but I am interested in the trade-offs for clients who do not want another account.

This is a hypothetical design question, not a claim about any product’s current implementation.

Custom Web App Cost in 2026: Pricing & Scoping Guide

Thu, 22 Oct 2026 14:40:41 +0000

You have a solid idea. Maybe it's a client portal, a SaaS product, or an internal tool that your team desperately needs. Then you ask a developer or three what it'll cost, and you get answers ranging from $3,000 to $300,000. That gap isn't a mistake. It reflects how wildly different custom web app cost can be depending on what you're building, who builds it, and where they're located.

This post won't give you a single magic number. Instead, it gives you a working framework: what drives cost, what you can expect at each budget tier, how to avoid common traps, and what a realistic project scope looks like. By the end, you'll be able to have a real conversation with a developer not a guessing game.

Want a faster gut-check first? Run your project through the free cost estimator and get a rough range in under two minutes, no email required.

What Actually Drives the Cost of a Custom Web App

Before any pricing makes sense, you need to understand the inputs. Costs aren't arbitrary. They break down into a handful of levers you can actually control.

Scope and feature complexity is the biggest driver. A simple CRUD app with user authentication and a dashboard is not the same as a multi-tenant SaaS platform with role-based permissions or Stripe billing integrations and real-time data. Each feature adds design time, development time, and testing time.

Team type and location is the second-biggest variable (see Clutch for rate trends). Here's the rough hourly rate landscape in 2026:

Team Type	Hourly Rate (USD)
US/UK/AU agency	$120 – $250/hr
European agency	$80 – $150/hr
Indian freelancer or agency	$25 – $75/hr
Solo specialist (India, niche)	$40 – $90/hr
No-code / low-code hybrid	$50 – $100/hr

Tech stack matters more than most founders expect. A Next.js (React), Prisma + PostgreSQL app costs less to build and maintain than a microservices architecture with custom DevOps. Don't over-engineer an MVP.

UI/UX design is often underbudgeted. Custom UI from scratch costs more than using a component library. Plan for at least 15–20% of your budget going to design.

Integrations Stripe, Twilio, third-party APIs, CRMs each adds days of work.

Post-launch costs: hosting, maintenance, bug fixes, and feature iterations are ongoing. Budget for them.

Cost Tiers: What You Get at Each Budget Level

Rather than a single estimate, think in tiers. Here's a realistic breakdown (see the full service and pricing breakdown for D Tech's current starting prices by project type):

Tier 1: $1,000 – $10,000 Lean MVP

Best for: validating an idea, landing a first client, or building an internal tool.

4–8 weeks of development
1 or 2 core features only
Simple UI using a component library (no custom design system)
Basic auth, database, and deployment
Usually a solo developer or small offshore team

What you won't get: polished UX, complex business logic, third-party integrations, or scalable architecture. That's fine this tier is for learning, not scaling. This is exactly the tier D Tech's MVP development service is built for, with builds starting at $1,000.

Tier 2: $10,000 – $40,000 Production-Ready V1

Best for: early-stage SaaS, client-facing portals, marketplace MVPs.

6–16 weeks of development
Core feature set with proper UX
User authentication, roles, billing (e.g. Stripe)
1–2 third-party integrations
Mobile-responsive, deployed on a managed cloud platform
Small team: lead developer + designer, or experienced full-stack agency

This is the sweet spot for most funded startups and bootstrapped founders who've validated demand.

Tier 3: $40,000 – $150,000 Scalable Product

Best for: Series A+ startups, enterprise tools, regulated industries (fintech, healthtech).

Full product team for 3–6 months
Advanced features: real-time data, complex permissions, analytics dashboards
Custom design system, accessibility compliance
Robust test coverage, CI/CD pipeline, monitoring
Likely involves a small agency or 3–5 person team

Tier 4: $150,000+ Enterprise-Grade

This is bespoke software at scale multi-region deployments, dedicated security reviews, compliance (SOC 2, HIPAA), and long-term team contracts. Most startups don't need this on day one.

A Realistic Scenario: SaaS Client Portal Built by D Tech

Consider a US-based logistics company that needs a client-facing portal: customers can log in, track shipments, upload documents, and generate invoices. Nothing exotic but nothing trivial either.

Here's how that project breaks down:

Features scoped:

Authentication + role-based access (client vs. admin)
Shipment tracking dashboard with status updates
Document upload (S3-backed)
Invoice generation (PDF export)
Basic email notifications

Estimated timeline: 8–10 weeks

Estimated cost with D Tech: $12,000 – $18,000

That same project with a mid-market US agency would likely run $45,000 – $70,000. The difference isn't quality it's overhead, location, and team size. D Tech operates as a lean, senior-led solo agency based in India, which means clients get a direct line to the person writing the code, without account manager layers or inflated estimates.

The tech stack used would be Next.js (React), Prisma + PostgreSQL, AWS S3, and Stripe modern, maintainable, and easy to hand off or extend.

This is the kind of scoping conversation D Tech has before quoting anything. There are no discovery fees, no vague "starting from" numbers.

5 Mistakes That Blow Up Web App Budgets

Most projects don't fail because of bad developers. They fail because of avoidable planning mistakes. Here are the most common ones:

1. Scoping too wide from day one. Founders list every feature they've ever imagined, then wonder why the quote is $80,000. Start with the smallest version that delivers value to a real user. Ship it. Then add.

2. Skipping the technical spec. A vague brief produces a vague (and low) quote that balloons post-kickoff. Insist on a written scope with feature list, user flows, and acceptance criteria before any work starts.

3. Choosing on price alone. The cheapest quote often comes with the highest hidden costs rework, delays, and eventually a rewrite. Look at portfolios, ask for references, and check whether the developer actually understands your domain.

4. Underestimating ongoing costs. A $15,000 build can cost $500–$2,000/month to maintain, host, and support. If your developer disappears after launch, you're stuck. Factor in a retainer or a handoff plan.

5. Not budgeting for design. "We'll use a template" often ends with a product that users don't trust. For client-facing apps, design is not optional—it's conversion infrastructure (read about why poor design and UX lose customers).

Conclusion

Custom web app cost in 2026 depends almost entirely on what you're building and who's building it. A lean MVP can be done well for under $15,000. A production-grade SaaS typically lands between $20,000 and $60,000. Enterprise software goes higher, but most founders reading this aren't there yet.

The smarter question isn't "how much?" it's "what's the smallest version that proves this works?" Answer that first, then find a builder who'll give you a straight number. If you are planning a first version, our MVP development page shows how we scope and ship one in 4–8 weeks. Comparing quotes across countries? See MVP development cost in India vs the US.

If you're ready to scope your project, D Tech's approach to custom web and SaaS development is built for high-ticket clients across the US, UK, EU, and Australia. No fluff, no middlemen just clean code and honest timelines. Book a free discovery call at dtechsolutions.tech/contact.

Multi-Tenant SaaS: Shared Database or One Per Tenant?

Wed, 21 Oct 2026 00:03:21 +0000

If you are building a SaaS product for more than one customer, you will have to answer one early question: how do you separate each customer's data? The choice between a shared database and a database per tenant shapes security, cost, performance and how painful your first enterprise customer will be.

I make this decision with founders as part of SaaS development work. This guide explains the three common models, when each fits, and the mistakes that are expensive to fix later.

What "multi-tenant" means

A tenant is one customer account, usually a company with its own users and data. A multi-tenant system serves many tenants from one codebase and one deployment. The alternative, running a separate copy of the whole app per customer, is single-tenant, and it gets hard to maintain quickly.

Multi-tenant design answers two questions:

Isolation: how do you make sure tenant A can never see tenant B's data?
Operations: how do you migrate, back up, scale and support many tenants without the work growing with every new customer?

The three data models

1. Shared database, shared schema

All tenants live in the same tables. Each row has a tenant_id column, and every query filters by it.

Strengths

Cheapest to run and simplest to start
One migration updates everyone
Easy to report across tenants

Weaknesses

One missed filter leaks data between customers
A very large tenant can slow everyone down ("noisy neighbour")
Restoring a single tenant from a backup is awkward

2. Shared database, separate schema per tenant

Tenants share a database server, but each gets its own schema, such as separate sets of tables.

Strengths

Stronger separation than a tenant column
Per-tenant backup and restore is easier

Weaknesses

Migrations must run once per tenant, which gets slow with many tenants
Tooling and connection handling are more complex

3. Separate database per tenant

Each tenant has its own database.

Strengths

Strongest isolation, which helps with security reviews and regulated customers
A tenant's data can be moved, backed up or deleted on its own
Heavy tenants don't affect the others' queries

Weaknesses

Highest operational cost and complexity
Migrations and monitoring multiply with each tenant
Cross-tenant reporting needs extra work

Microsoft's architecture guidance on tenancy models describes the same trade-off between isolation, cost and operational effort, and is worth reading alongside this.

How to choose: five questions

1. Who are your customers? Many small customers point toward a shared database. A few large or regulated customers who ask about data isolation point toward separate databases.

2. What are the compliance expectations? If customers need contractual guarantees about data separation, or data residency in specific regions, a separate database makes those promises easier to keep.

3. How uneven will tenants be? If one tenant could be a hundred times bigger than the average, plan for isolating heavy tenants early.

4. How big is the team? Every extra database is something to monitor, migrate and back up. A small team should choose the simplest model that meets the requirements.

5. How will you grow? Many products start shared and move their largest customers to dedicated databases later. A design that allows this is more valuable than a perfect choice on day one.

My default for early-stage SaaS

For most early products I start with a shared database and a tenant_id on every tenant-owned table, and I build the safeguards in from day one. This keeps cost and complexity low while the product finds its market, and it does not close the door on moving large customers out later.

The key is that "shared" must not mean "careless". The safeguards I add:

A global scope or middleware that applies the tenant filter automatically, so developers can't forget it
Database-level protection where the database supports it. PostgreSQL's row-level security can enforce tenant filtering even if application code has a bug.
Tenant-aware tests that fail if a query returns another tenant's rows
Composite unique keys that include the tenant, so two customers can use the same email or slug
Tenant context in logs and jobs, so background work never runs without knowing whose data it touches

If you use Laravel, packages such as Tenancy for Laravel support both single-database and multi-database approaches, which helps you start simple without being locked in.

Common mistakes

Forgetting background jobs. Queued jobs, scheduled tasks and webhooks run outside a web request, so the tenant context can be missing. Pass the tenant explicitly, as I describe in my guide to Laravel queue architecture.

Leaking through shared resources. Caches, search indexes and file storage need tenant-aware keys and paths, not only database rows. See secure multi-tenant file storage in Laravel.

Global unique constraints. Uniqueness rules that ignore the tenant make customers collide with each other.

No plan for super-admin access. Support staff need to view tenant data, and that access should be controlled and logged. My article on audit logging for SaaS compliance covers this.

Choosing separate databases too early. It feels safer but multiplies operations for a product that may only have a handful of customers.

Cross-tenant reporting as an afterthought. Analytics across tenants are easy in a shared schema and hard with many databases.

A real-world example

On Imperial Votes, a multi-tenant competition platform I built on Next.js and Prisma, organizers run their own competitions with branding tools, role-based permissions and dashboards, while super-admin controls sit above them. That mix of customers acting independently under one platform is exactly where the tenancy decision matters. The Imperial Votes case study shows how the product grew, and the matching write-up on building a multi-tenant voting SaaS goes deeper.

What to decide before you write code

Before the first migration, write down answers to these:

What is a tenant in our product (a company, a team, a workspace)?
Which tables belong to a tenant, and which are global?
How is the tenant identified on each request: subdomain, path or login?
How will background jobs and webhooks know the tenant?
What would force us to move a customer to a dedicated database?
How do support staff access tenant data safely?

Answering these costs an afternoon. Changing the model after launch costs months.

Moving a large tenant to its own database later

If you design for it, moving one customer out of the shared database is a manageable project rather than a rewrite. The usual steps:

Create the new database with the same schema and run the same migrations.
Copy the tenant's rows across, using the tenant_id to select exactly what belongs to them.
Verify counts and key records, and keep the old data until the checks pass.
Switch the tenant's connection so requests resolve to the new database.
Remove the tenant's rows from the shared database once you are confident.

This only works if every tenant-owned table carries the tenant identifier, files and caches are tenant-scoped, and your application resolves the database connection from the tenant. Those are the same safeguards that keep the shared model safe, which is why I add them from the start.

Key takeaways

Multi-tenancy is mostly about isolation and operational cost.
Shared database with a tenant column is the cheapest start. Separate databases give the strongest isolation.
Add safeguards such as global scopes, row-level security and tenant-aware tests so shared never means careless.
Plan for jobs, caches, files and support access, not only database tables.
Design so you can move large tenants out later.

If you are planning a SaaS product and want the architecture settled before you build, book a call and we can map the tenancy model to your customers and budget.

Originally published at aqibjavaid.site.

Website vs Web App: How to Choose for Your Business

Tue, 20 Oct 2026 14:05:01 +0000

You've got a business idea - or an existing business that needs a stronger digital presence. You know you need something built. But somewhere between your first conversation with a developer and your second invoice for a discovery workshop, a question starts nagging you: am I building the right thing?

The website vs web app decision trips up founders and business owners more than almost any other early-stage call. Get it wrong and you either overspend on complexity you don't need, or you underbuild and hit a wall six months later when your product needs features your "brochure site" simply can't support.

This guide gives you a clear, practical framework for making that decision - no fluff, no jargon spiral. By the end, you'll know exactly which one fits your goals, your budget, and your timeline.

What's the Actual Difference Between a Website and a Web App?

People use these terms interchangeably, but they describe fundamentally different things.

A website is primarily a content delivery tool. It presents information to visitors - who you are, what you do, how to contact you. The visitor consumes content; they don't produce it. Think marketing sites, portfolios, blogs, and service pages. The user interaction is largely one-directional.

A web app is an interactive software product that lives in a browser (see MDN Web Docs' guide on Web Applications). Users log in, create accounts, submit data, trigger actions, and get personalised outputs. Think Notion, Stripe, Shopify, or any SaaS dashboard. The interaction is two-directional - the user is doing something, not just reading something.

A few sharper distinctions:

Factor	Website	Web App
Primary purpose	Inform / convert	Enable user to do something
User accounts	Rarely needed	Almost always required
Data storage	Minimal	Central to the product
Complexity	Low-Medium	Medium-High
Time to build	Days to weeks	Weeks to months
Typical cost (custom build)	$2,000-$10,000	$10,000-$80,000+
Hosting model	Static or CMS	Server, database, APIs

None of this means websites are "lesser." A well-built website converts customers, ranks on Google, and runs at near-zero maintenance cost. The mistake is building a web app when a website would have done the job - or vice versa.

How to Choose: A Decision Framework

Start with these four questions. Your answers will point you clearly in one direction.

1. Does the user need to log in?

If your product is meaningless without a user account - saved data, personal dashboards, subscription access - you need a web app. If the goal is to get someone to read, browse, or contact you, a website is sufficient.

2. Is user-generated data core to the product?

If users create, store, or manipulate data (invoices, bookings, content, files), that data needs a backend. Web app territory.

3. Are you selling software-as-a-service - or selling your services?

An agency, consultant, or product company selling their own work typically needs a website first. A founder building a tool that others pay to use needs a web app.

4. What's your runway?

A web app built right requires proper architecture: authentication, database design, API structure, security hardening (adhering to standards like Vercel's security practices), and deployment pipelines. If you have 4-6 weeks and a tight budget, a polished website can generate leads and validate your offer while you plan the real build.

The honest shortcut: If you're at the "prove the idea" stage, build the website first. When users are asking "can I do X inside this?" - that's your signal to build the app. Scoping that validation phase tightly, with only the features needed to test your core idea, will save you time and money.

A Real-World Example: Two Founders, One Wrong Call

Consider two hypothetical founders - both B2B SaaS ideas, both early-stage.

Founder A runs a consulting firm that helps mid-market companies with supply chain audits. He wants to "build his platform." After a $40K investment, he has a web app with a client portal, document upload, and a reporting dashboard. Six months in: he has three clients, all of whom email PDFs anyway and never log into the portal. A $5,000 website with a strong case study page and a Calendly booking flow would have served him better at this stage.

Founder B is building a tool that lets e-commerce brands automate returns processing. Her MVP needs user accounts, Shopify API integration, conditional logic, and a reporting layer. She initially tried to "start with a simple website." Two months in, the developer explained why a static site couldn't do what she described. She lost eight weeks.

At D Tech, these are the exact conversations we have in discovery calls. The output - website or web app - follows from understanding what the product actually needs to do, not what sounds more impressive in a pitch deck. We outline this structured approach in our guide on How We Build Custom Web Apps for High-Ticket Clients.

When clients come to us with a fuzzy brief, the first question isn't "what tech stack do you want?" It's "what does a user do inside this thing?" That single question almost always clarifies the path forward.

Common Mistakes to Avoid

1. Over-engineering too early

Building a full web app to test a hypothesis is expensive. According to CB Insights research on why startups fail, building a product without market need is the number one cause of failure. A landing page + waitlist can validate demand in a week. Build software after you have evidence people want it.

2. Using a website builder when you need a web app

Webflow, Framer, and Squarespace are excellent tools for websites. They're the wrong foundation for anything that requires persistent user data or complex business logic. Don't let a no-code tool choice box you into an architecture you'll have to rebuild.

3. Confusing "interactive" with "web app"

A website can have animations, forms, calculators, even live chat - and still be a website. Interactivity doesn't automatically make something a web app. The line is whether data is being stored per user and acted upon over time.

4. Ignoring maintenance costs

Web apps require ongoing attention: security patches, dependency updates, infrastructure costs, and feature requests. Budget 15-20% of build cost annually for maintenance. Websites cost far less to maintain.

5. Hiring for the wrong deliverable

A freelancer quoting you a "website" when you described a web app workflow is a red flag. Make sure the person you hire can articulate the architecture they'll use and why - not just show you a portfolio of nice-looking pages.

Make the Right Call Before You Spend a Pound or Dollar

The website vs web app question isn't really a technical one. It's a product strategy question dressed in technical clothing. Answer "what does a user need to do?" honestly, match it against your timeline and budget, and the right choice becomes obvious.

If you're still unsure, that's what discovery calls are for. At D Tech, we help founders and business owners scope the right product from the start - not reverse-engineer a bad decision six months later. Whether you need a high-converting website or a production-ready web app, we build custom solutions for clients across the US, UK, EU, Australia, and UAE.

Book a free discovery call, or see how D Tech scopes websites and web apps for founders before a line of code gets written.

ShipTok: Scroll feed for builders

Tue, 20 Oct 2026 09:21:39 +0000

ShipTok - TikTok for Indie Hackers Shipping in Public

I got tired of building in silence. Twitter is noisy, Product Hunt is once-per-ship. I wanted a place where we can ship every day and get instant feedback.

So I built ShipTok.

Live: https://shiptok-app.vercel.app/ (first 20 signups get pro for 7 days 🚀)

The Story

I was shipping small projects but no one saw them. I'd post on X and it would drown. I realized builders don't need another social network - they need a shipping feed.

The idea is simple: If you shipped today, you post. No fluff, no growth hacks - just proof of work.

How it Works

Create your Builder Profile - Claim your username, add your GitHub/Twitter, write your bio.
Ship Something - Posted a feature? Fixed a bug? Launched? Post a 1-min video / screenshot / log.
Get on the Feed - Your ship appears in the global feed. Other builders hype you up, follow, and get inspired to ship too.
Build Your Streak - Profile shows your shipping history. Verified builders get a badge (paid).

It's like GitHub contributions graph, but for your actual products and with people cheering.

Key Features

Builder Profiles

Custom username, name, bio, avatar.
GitHub & Twitter links.
Shipmoji identity (your builder emoji).
Paid verification for real builders.
Email privacy toggle.

The Ship Feed

Short-form shipping updatesbwith media (shirt video/ up to 4 screenshots)
No algorithm BS - chronological feed of real work
Inspired by TikTok's fast consumption

Community First

Follow builders you like
Comment & hype others
Show your profile completion and level up

Screenshots

How You Can Get Involved

I just fixed the big auth bug that was blocking signups (500 on /callback), so now it's open for everyone.

Ship your first project: https://shiptok-app.vercel.app/ — create profile and post what you shipped today.
Give feedback: What feature would make you come back daily?
Share: If you like the idea of building in public, share it with your builder friends.

I'm @temi0x0 on ShipTok — come say hi and show me what you shipped today!

Let's make shipping as addictive as scrolling.

Built with ❤️ by builders, for builders.

Can One Developer Beat Big Tech? Sideways, Yes.

Sat, 17 Oct 2026 01:56:50 +0000

Let me start with a confession. Bitly's cheapest plan with a custom domain was listed at around $29 a month. I looked at my wallet. My wallet looked back with concern.

So I did what any reasonable developer does when the price is too high: I built my own. That's how Fewly was born.

"Compete with the tech giants" sounds like a movie trailer, I know. One guy, one laptop, one dream, and 47 open browser tabs. But stay with me, because the trick is not what you think.

You don't fight giants. You find the gap.

Big companies are cargo ships. Huge, powerful, and very busy chasing enterprise contracts. Freelancers, students and small creators are not on their radar, so the pricing slowly drifts toward whoever owns a corporate card.

I'm a speedboat. I can't carry 10,000 containers, but I can park in the small harbor nobody else bothers with.

Cuttly is kinder than Bitly, with paid plans from about $12 a month. Prices change, so check them yourself. The point is that the gap I found was not a missing feature. It was a missing price.

So what does Fewly do?

Paste a long URL, get a short one. No account needed. Then it gets more interesting:

Free: 50 links a month, 30 days of analytics, basic QR codes.
Pro, $5 a month: unlimited links, branded domains, 1 year of analytics, API.
Team, $9 per seat: workspaces, roles and an audit log.

Honest note: branded domains are a Pro feature, not free. But branded short links at $5 instead of $29 is a conversation a freelancer can actually have.

The blockers (aka the fun part)

Blocker 1: My first QR generator was embarrassing. It made a QR code for a link. That's it. A QR generator that only does links is a Swiss Army knife with one blade, which is just a knife. So I added WiFi, WhatsApp, vCard, email, SMS, location, social and payment codes.

Blocker 2: DNS. Custom domains need DNS records, and DNS is the one place on the internet where everyone is equally confused. So now Fewly shows you the exact records to add, verifies them, and sets up HTTPS on its own. Fewer tears all around.

Blocker 3: People will shorten sketchy stuff. Of course they will. So every link is scanned for malware and phishing, and anything pointing to private or internal addresses gets refused. Turns out a link shortener also has to be a bouncer.

Then I got carried away and built tools

Fewly now has 73 free browser tools. No signup, no uploads, no watermarks. Everything runs on your own device, which also keeps my server bill small. That's the only reason "free" survives.

My favorites:

Online DB Viewer. Drop in a SQLite file, browse tables and run real SQL with the online DB viewer. The file never leaves your machine. Perfect for that moment when you pull a database out of an app and wonder what's inside.
Text to Handwriting. The text to handwriting tool turns typed text into ruled notebook pages. To be clear, it's a handwriting font, not a clone of your own writing. Use it for worksheets and cards, not for crimes.
QR Code Generator. A free QR code generator with PNG and SVG download. No signup, no watermark, and yes, it does more than links now.
Payment Fee Calculator. On a $5 sale, Stripe's $0.30 fixed fee eats nearly 9%. The payment fee calculator shows what actually lands in your account. Want to receive exactly $500? Charge $515.24, not $514.50. Math is sneaky like that.

What I learned

1. Hunt for gaps in price, privacy and speed. Features are easy to copy. A fair price is harder.

2. Free tools are a front door. Someone comes for a JSON formatter, leaves in ten seconds, and now knows my name.

3. Be honest. Bitly has a name everyone knows, years of trust and enterprise clients. Fewly is young. I'm not claiming a win. I'm saying one small corner of the market was underserved.

So, can a solo dev still compete?

Not head on. Sideways, absolutely.

Try Fewly and tell me what's missing. I read every message, mostly because I'm the only one here.

SaaS MVP Cost: What to Expect and How to Spend Less

Fri, 16 Oct 2026 11:36:26 +0000

How Much Does a SaaS MVP Cost?

Your SaaS MVP cost is decided mostly by four things: how many features you launch with, whether people need accounts to log in, whether you take payments, and how polished the design has to be. A focused MVP built around one core workflow costs [ADD MY RANGE] with me and takes [ADD MY RANGE] to build. Every feature you add beyond that raises both numbers, which is why the smartest way to save money is to launch smaller than you think you need to.

I'm Anas, a full-stack Next.js developer. I build SaaS products, custom websites and premium templates. Next.js is a popular tool for building fast web apps, and that is all you need to know about it. Below is what founders usually want to understand before they ask for a quote.

What an MVP Is, and What It Is Not

An MVP (minimum viable product) is the smallest working version of your product that real people can use, so you can learn whether they want it before you spend more.

It is not a finished product with every feature you can imagine. It is also not a prototype. A prototype is a clickable mock-up that looks real but does not actually work behind the screens. A prototype is cheaper and useful for testing an idea on paper. An MVP is real software that people can sign up for and use. I explain the difference in more detail in MVP vs prototype.

An MVP is also not a throwaway. A good one is the foundation you keep building on, so the basics, like security and how your data is stored, need to be done properly even when the feature list is short.

What Drives the Price of a SaaS MVP?

Six things move the price more than anything else:

Number of features. Each feature has to be designed, built and tested. Ten features cost far more than three, and the later ones are rarely the ones users care about most.
User accounts and login. Letting people sign up, log in and reset a forgotten password is standard, but it takes real work. Different types of users, such as customers and admins who see different screens, add more.
Payments. Charging a monthly subscription through a payment provider means handling plan changes, failed cards, refunds and receipts. A product that is free at launch, or invoiced by hand, is cheaper to start.
Dashboards. A dashboard is the screen where a user sees their own data, often as tables and charts. Simple summaries are quick to build. Filters, exports and live-updating charts take longer.
Third-party integrations. An integration connects your product to another service, such as your calendar, email or accounting tool, usually through an API (a way for two programs to talk to each other). Each one adds build time and one more thing that can break later.
Design level. A clean layout built from proven design components costs less than fully custom branding, animations and illustrations.

If you also need a marketing website to sell the product, that is a separate project with its own price. I break that down in how much a website costs in 2026.

What Do a Small, Medium and Larger MVP Include?

These tiers are a general guide to scope, not a quote. What goes into your MVP gets decided in a written scope before any work starts.

Small MVP: one core workflow. One main thing the product does, simple sign-up and login, one or two main screens, basic design, and no payments (or payments handled by hand at first).
Price: [ADD MY RANGE]. Timeline: [ADD MY RANGE]. [ADD MY EXAMPLE]

Medium MVP: the core workflow plus the business basics. Everything in the small version, plus subscription payments, a user dashboard, an admin area where you manage users and data, and one or two integrations.
Price: [ADD MY RANGE]. Timeline: [ADD MY RANGE]. [ADD MY EXAMPLE]

Larger MVP: more than one type of user. Several user types with different permissions, more dashboards and reports, several integrations, email notifications and a custom design.
Price: [ADD MY RANGE]. Timeline: [ADD MY RANGE]. [ADD MY EXAMPLE]

If your idea needs more than the larger tier, that is usually a sign the first version should be split into stages. You can see the kinds of projects I take on on my services page.

How to Lower Your SaaS MVP Cost Without Making the Product Worse

The goal is to spend less without shipping something people cannot trust. These cuts usually hurt the least:

Launch with one core workflow. Pick the single thing your product must do well and cut everything else from version one.
Use proven tools instead of building from scratch. Existing services for login, payments and email are cheaper and more secure than custom versions of each.
Do some steps by hand at first. If a feature would take weeks to automate, you can do it manually for your first ten customers and automate it once you know it matters.
Delay the nice-to-haves. Notifications, multiple languages, dark mode and detailed analytics can wait for version two.
Keep the design simple. A clean, consistent layout builds more trust than a complicated custom one.
Write the scope down. Changing your mind in the middle of the build is the most common reason projects go over budget.

Costs People Forget After the MVP Is Built

The build is not the only cost. Plan for these as well:

Hosting. The servers where your product runs. It is usually a monthly cost that grows with your number of users.
Domain name. Your web address, paid yearly.
Email service. Sign-up emails, password resets and receipts need a service that sends them reliably.
Payment fees. Payment providers take a percentage of each transaction plus a small fixed fee. Check the current rates with your provider.
Maintenance after launch. Software needs updates, bug fixes and security patches. Ask any developer what this costs and who does it. For my work: [ADD MY RANGE].

Who This Is For

This is for a non-technical founder or business owner with a specific SaaS idea, a limited budget and no clear sense of what to expect from a developer. It also helps if you already have a quote and want to know whether it is reasonable.

Who This Is Not For

If you have not talked to a single potential customer yet, the first step is not building anything. Start with how to validate your SaaS idea. This is also not the right page if you need a finished, feature-complete product with no budget limit, or a native mobile app, which is a different kind of build.

What to Prepare Before Asking a Developer for a Quote

The problem you solve and who has it, in two sentences.
Your core feature, the one thing the product must do on day one.
Your budget range. A real number you can commit to, not a hope.
Your deadline, and whether it is tied to a launch date, an event or funding.
Examples of products you like, for how they look or how they work.
Whether you take payments at launch.
Who will use it, such as customers only, or customers and an internal team.

Frequently Asked Questions

Can I build a SaaS MVP on a small budget?

Yes, if you keep it to one core workflow and use proven tools for the standard parts. My smaller builds start at [ADD MY RANGE]. Budgets get tight when you try to launch with a long feature list.

Should I pay a fixed price or by the hour?

A fixed price works when the scope is written down and clear, which is the case for most MVPs. Hourly works better when you are still figuring out what to build. Either way, agree on what is included before work begins.

Will I own the code?

You should, and you should get that in writing before you pay anything. Ask any developer this directly.

How long until I can launch?

A focused MVP takes [ADD MY RANGE] with me from a confirmed scope. A larger one takes longer, and the real timeline should come from your written scope, not a general rule.

What to Send Me

Send me four things and I will reply with an honest view of what fits your budget: what your product does and who it is for, your core feature, your budget range, and your deadline. If you have links to one to three products you like, include them. With that, I can give you a realistic SaaS MVP cost and tell you what I would build first.

Send it through pixelanas.com/contact.

Anas, full-stack Next.js developer building SaaS products, custom websites and premium templates.

I built PinOps to turn a published URL into useful Pinterest pins

Tue, 13 Oct 2026 15:47:07 +0000

I kept losing afternoons after an article was already live.

Pinterest still needed useful pins from that URL: more than one angle, vertical creatives that match the destination, titles that stay honest to the link, and a queue that does not dump twenty pins in a day. The calendar was never the hard part.

So I built PinOps.

Paste a published URL. Get useful pins. Edit what needs a tweak. Queue what you keep.

https://pinops.app

Freemium. Bootstrapped. I built it because I was tired of rebuilding that path every time a post went live.

If you have tried to turn a blog into a Pinterest system, I want to hear where the time actually goes.

My content system looked organised. It still couldn’t tell me what was live.

Sat, 10 Oct 2026 10:27:29 +0000

I had one source library, separate platform documents, and no trustworthy answer to the simplest question.

I made separate Instagram and YouTube upload documents for the same videos intended to promote my app. At the time, I was promoting a note-taking app I had built after work, and keeping each platform’s copy, links, media notes and upload details in its own file felt sensible.

They were supposed to stay in sync, which is the sort of sentence that sounds completely reasonable until two files have had a few months to develop independent lives.

When I opened them again, they no longer described the same library. Instagram listed videos YouTube did not. One Instagram entry still carried a YouTube tracking link. The calendar offered a third version of the week, although a row could mean planned, drafted, scheduled, attempted or genuinely public depending on when I had last touched it.

None of this came from one dramatic failure. I had simply been sloppy about keeping every copy updated, and the files had drifted far enough apart that I could no longer trust any of them.

One source library. Two upload documents. Several answers to what existed.

At first, I treated it as a bookkeeping problem. Then I tried to follow one post backwards from its public URL to the idea that had started it. That trail led through the upload documents, the calendar, the exported media and, eventually, the research system where the content had begun.

The system started with a sensible idea

I did not want to invent random posts and hope somebody cared. I started with questions people were already asking about iPad notes, Apple Pencil workflows, lecture notes, handwriting, organisation, summaries and exports. I searched for them manually on the platforms where those questions came up.

Those questions became the source material for the content. I kept the supporting notes in an LLM-backed knowledge base so a popular search phrase could not turn straight into a confident answer I could not support.

The goal was not to produce as many ideas as possible. It was to separate topics I could answer responsibly from topics that needed better evidence, fell outside the app or simply were not useful enough.

That distinction mattered around claims. A query containing “best” needed a real comparison. Prices had to be checked again before publishing. Statements about another app needed an official source, and recognition accuracy needed testing rather than optimism.

From there, the strongest answers could become short educational carousels or videos. The source would remain the same, but the presentation would later have to change for Instagram, TikTok, YouTube and anywhere else I wanted to publish it.

For a topic to move forward, its registry entry needed enough supporting material to survive that process. This gave me a useful difference between something people searched for, something I could answer and something I was genuinely ready to produce.

The research system worked. It could even reject an idea.

Research kept growing because it felt like progress

It also gave me an endless supply of tidy work. I could refine another query, check another claim or clean another row and finish the evening with a better-organised registry.

“Ready” still meant I had permission to begin.

The topic needed a script, visuals, real product screens, layout, exports and a separate version for each destination. Even a short five-slide carousel could absorb an evening before I had prepared a single upload.

When I compared the registry with the published feed, the imbalance became obvious. I had a growing bank of defensible topics and only a few finished carousels at the other end.

Deciding what deserved to exist was no longer holding me back. Moving one decision all the way to a public post was.

The difficult work began after approval

Once a topic cleared the research stage, it entered a different system.

The same underlying idea might become a carousel, a short video, an X post, an Instagram caption and a YouTube title and description. The useful observation stayed the same. Almost everything surrounding it changed.

I kept scripts, media, exports and upload instructions in separate places because each place made sense on its own. The separation became a problem as soon as I revised anything.

Updating the source did not update the Instagram copy. Fixing the title in the YouTube document did not change the calendar. Scheduling a post did not confirm that the provider had accepted it, and acceptance still did not prove that somebody else could see it.

The calendar could not repair those gaps. Putting an item on Tuesday made the week look organised, but Tuesday could mean planned, ready, scheduled, attempted or public.

Those states had gradually collapsed into one another. That was why the documents at the beginning of this story disagreed: none of them represented the complete journey.

I was saving outputs instead of their source

I had treated the final caption as the thing worth reusing. It should have been the real source underneath it.

That source might be a feature I had built, a question from the research registry, a result from a previous post or something I had learned while fixing a bug. The event and its evidence should remain stable while the presentation changes for each destination.

On X, I can spend more time on the reasoning. On TikTok, the useful visual has to arrive almost immediately. Instagram may begin with similar material but still needs its own framing. YouTube needs another title, description, thumbnail and link setup.

Copying one finished caption into every box was fast. It also produced a version that fitted nowhere particularly well.

The workflow I needed was simple enough to explain:

one real source
→ native platform versions
→ human review
→ schedule
→ provider result
→ confirmed public post

I was still the only thing keeping those steps connected. Once I wrote the process down like that, the mismatched documents stopped looking like a filing mistake. They were separate files trying to remember one shared process.

That missing connection became Sendezeit

Sendezeit grew out of that missing connection.

It starts with something that actually happened, then keeps the destination versions, media, edits, approvals, calendar entries and provider results attached to the same source.

The software can help adapt the material, but it does not decide what is worth saying or approve the final version for me. Those decisions remain mine.

It solves one specific problem

Sendezeit does not tell me whether the post was good, whether the audience cared or whether the product converted. Those questions still belong in the content, the product and the analytics.

What it can tell me is whether the right version reached the right destination, what the provider returned and where the public result lives.

You can build the same workflow in a spreadsheet: keep one source, write the platform versions beside it, review each one, add the schedule and record the final public URL. I had pieces of that system already. I built Sendezeit because maintaining the connections between them had become another job.

That brings me back to the upload documents. Their real problem was not that one contained more rows or information than the other. I had asked two separate files to remember a single moving workflow, then acted surprised when they represented it differently.

The question that started all of this was not “What should I post next?”

It was “What actually made it live?”

That sounds less exciting. It was also the question I needed the system to answer.

Thanks for reading.

What I Built in the Last Year: A List of Failures

Thu, 08 Oct 2026 09:00:20 +0000

title: What I Built in the Last Year: A List of Failures
published: true
date: 2026-10-05 01:51:51 UTC
tags:

canonical_url: https://blog.nandan.dev/what-i-built-in-the-last-year-a-list-of-failures

A list of failures.

That's the most accurate title I could come up with. Here's the summary:

In the last year or so, I have built 4 web apps, 3 open-source tools, wrote one book, onboarded 250+ users overall, and made 25 dollars overall.

Read that sentence a few times. Eight projects and 250+ users went in, and 25 dollars came out. That isn't a monthly number or a per-project number. It's the total.

I'm not writing this to ask for sympathy, or to pretend it was all a learning experience. Some of it was. Mostly, I want the numbers written down in one place, because the gap between building something and getting someone to pay for it is easy to ignore when you only look at one project at a time.

The web apps

These are the ones where revenue was supposed to happen.

Bailoutt.com - Fake AI calls and call reminders - live ~200 users, 2 paid
https://chunkybabies.com - Baby health tracker - 2 users, didn’t take off. Offline now
Kitaaben - Book tracker, journal and AI reviews. - 60+ users - 1 active subscriber
WO Buddy - Build your exercise plan, with illustrated guide - 10 users - none paid

Put those side by side, and you get a funnel that starts wide at "built" and ends at a few coins at "paid."

The open source tools

I never expected these to make money. They're free, they solved my own problems, and a couple of them might solve yours.

GWDAP - Automate verification and adding aliases for multiple domains.
COPE agent - A multi-model content repurposing tool that turns any provided source into a canonical brief, which in turn converts it into multi-format content, i.e. long form like LinkedIn, short form like Twitter, etc., carousel, both image and and pdf
DoCk - A browser extension that routes your Google Workspace links to their respective PWAs rather than opening a new tab for each link.

The book

Dad, Debriefed - Journaled my experience as a father and turned it into a book that works as a guide to new fathers.

So where does that leave things?

Here's the scoreboard: 8 projects, 250+ users, $25.

You can read that a few ways. Turns out I'm good at shipping. Getting anyone to pay is a separate skill, and the list shows I haven't learned it yet. Every one of these went live. Most of them found at least a handful of people. Almost none of them found people with a reason to pay.

A few things I'm taking from the year:

Shipping is not the bottleneck. I can build things. That clearly isn't what's holding me back.
Users are not customers. Bailoutt has about 200 users and 2 paying ones. That ratio says a lot about what I've actually validated.
One paying subscriber counts. Kitaaben's single subscriber tells me more than its 60+ free users do.
Killing a project is fine. Chunkybabies is offline, and nothing broke.
Not everything has to make money. The open source tools and the book were worth doing anyway. I just shouldn't confuse them with a business.

So it's a list of failures, by the only number that pays rent. By the count of things that exist now and didn't a year ago, the year went better than that number suggests. Both readings are true. I'm just not going to pretend the second one cancels out the first.

Building My First Global SaaS Tool from Scratch

Sun, 04 Oct 2026 09:34:40 +0000

After some encouragement from my colleagues, I finally decided to build my own SaaS tool for the global market.

On September 8, I got a Mastercard that supports international payments. Right after that, I bought a domain, initialized the project, and started building.

The first version went live on day one.

As soon as it was deployed, I submitted the site to Google Search Console (GSC) and Bing Webmaster Tools, hoping to get it crawled and indexed as early as possible.

This post is a record of that process: choosing a domain, setting up the stack, deploying the product, working with AI coding tools, and figuring out a development workflow that works for a solo developer.

Choosing a Domain

I wanted to build a music-related utility site, so the first step was finding a suitable domain.

After comparing registrars, I found that the same domain was cheaper on Spaceship than on Namecheap, so I went with Spaceship.

I had read quite a few discussions about domain selection before starting. My main takeaways were:

If your budget allows, .com is usually the safest choice. .ai and .app are also worth considering.
Keep the domain short and easy to remember. Ideally, include a keyword related to the product.
Avoid hyphens, obscure English words, and random letter combinations whenever possible.

One reason .ai and .app can work well is search behavior.

People often search for phrases such as xxx app or xxx ai. If your domain naturally matches that intent, it can make the product easier to understand and remember.

At this stage, though, I did not want to spend too much money on a domain.

So I ended up buying:

musictool.tools

It costs roughly €6 per year.

Good enough for an early-stage experiment.

Setting Up the Project

For an SEO-driven product targeting international users, I prefer a stack that supports Server-Side Rendering (SSR).

The main reason is simple: search engines can receive relatively complete HTML directly, which reduces the amount of work required for crawling and indexing.

Because of that, I did not want to build the site as a purely client-rendered SPA.

This is also one of the reasons frameworks such as Next.js have become so popular among SEO-focused products.

That said, I personally find the Next.js development experience a bit heavier than I would like, so I chose TanStack Start (RC) instead.

For project initialization, I used an open-source stack generator I had used before:

https://better-t-stack.dev/

Once the initial scaffold was ready, I started adapting it to my own requirements with the help of AI.

Here is the stack I ended up using.

Engineering and Tooling

Category	Technology	Purpose
Monorepo	pnpm workspaces + Turborepo	Multi-package management and parallel builds
Language	TypeScript	End-to-end type safety
Code Quality	Oxlint + Oxfmt	Linting and formatting
Environment Variables	@t3-oss/env-core + Zod	Server and client env validation (`packages/env`)

Frontend and Full-Stack Framework

Category	Technology	Purpose
Full-Stack Framework	TanStack Start	SSR, file-based routing, Server Functions
Routing	TanStack Router	Type-safe routing and SSR integration
Build Tool	Vite 8	Development and production builds
SSR Runtime	Nitro	Server-side rendering and Vercel deployment support
UI Library	React	Component-based UI
Styling	Tailwind CSS v4	Utility-first CSS
Component Library	shadcn/ui (`packages/ui`)	Shared UI primitives
Icons	lucide-react	Consistent icon system
Theme	next-themes	Dark mode
Animation	Motion	Page and component animations
Notifications	Sonner	Toast notifications

Data and State Management

Category	Technology	Purpose
Server State	TanStack Query	Data fetching, caching, and SSR integration
Client State	Jotai	Shared UI and session state
Forms	TanStack Form	Form state and validation
API Layer	oRPC	End-to-end type-safe RPC with OpenAPI integration
ORM	Drizzle	TypeScript-first database access
Database	PostgreSQL	Primary data storage
Local Database	Docker Compose	Local PostgreSQL development environment

Authentication and Internationalization

Category	Technology	Purpose
Authentication	Better Auth	Sessions, social login, and TanStack Start integration
Login	Google OAuth	Third-party authentication
Internationalization	Paraglide JS + inlang	Compile-time i18n and locale-based URLs for SEO

AI

Category	Technology	Purpose
AI SDK	Vercel AI SDK	Streaming responses and Server Actions
Model Provider	@ai-sdk/google	Google model integration

Infrastructure and Third-Party Services

Service	Purpose
Vercel	Hosting, CI/CD, and Serverless Functions
Cloudflare	Domain DNS
Google OAuth	User authentication
Waffo Pancake	Subscription payments and Webhooks
Resend	Transactional email and user feedback
Cloudflare R2	S3-compatible object storage with presigned uploads
Google Analytics 4	Production traffic analytics
Microsoft Clarity	User behavior analytics and session recordings
Sentry	Frontend and backend error monitoring

Most of these services provide free tiers, which is more than enough for an early-stage solo project.

Payments

For payments, I chose Waffo, mainly because it is relatively friendly to independent developers.

I discovered it somewhat randomly while browsing online.

Stripe usually requires more preparation depending on where you are based, including considerations around business entities and banking.

I have not opened a Hong Kong bank account yet, so Waffo was the more convenient option for me at this stage.

The integration itself was straightforward.

I followed the official documentation, gave the relevant docs, prompts, and Skills to the AI coding agent, and let it handle most of the implementation.

If your setup allows it, Stripe is still worth evaluating based on your own business requirements.

Deploying the Product

Launching a small SaaS product today is much easier than it used to be.

Modern Serverless infrastructure is mature enough that lightweight SaaS tools often do not need a manually maintained server running 24/7.

Platforms such as Vercel and Cloudflare can handle most of the infrastructure for you while scaling automatically when necessary.

For this project, I connected the Git repository directly to Vercel.

Every push automatically triggers a new build and deployment.

There is almost nothing to manage manually.

At the current stage, deployment costs are also close to zero.

For object storage, I use Cloudflare R2.

Its free tier is generous enough for the early stage of the project, so storage has not added any meaningful cost yet.

The main expenses currently come from third-party APIs used by some features. Those require a small amount of prepaid credit, but the overall cost is still manageable.

For solo developers, the infrastructure barrier to launching a project has become extremely low.

You can build the first version almost entirely on free tiers.

Once the product has real users and revenue, you can upgrade infrastructure based on actual usage instead of guessing in advance.

My Development Process

The initial infrastructure setup took roughly one day.

After that, I moved on to actual feature development.

If you are unfamiliar with the target market, I think it makes sense to start with an AI-assisted research phase.

You can use AI Research tools to study competitors, identify common features, understand user expectations, and map out the basic product landscape.

In my case, I already knew this domain fairly well and had a clear idea of what I wanted to build.

So I went straight into AI Coding.

My development process has two main stages:

Design the feature.
Break down the requirements and implement them.

Designing with AI

For design work, I mainly use Pen.

After connecting it to DeepSeek and enabling x6, the overall design workflow became quite efficient.

My AI Coding Workflow

For implementation, I mainly use Matt's workflow.

The process looks roughly like this:

/grill me
Discuss the requirements with AI in detail and clarify the implementation approach.
/to-spec
Convert the discussion into a complete specification and high-level implementation plan.
/to-tickets
Break the plan into smaller tasks that can be implemented independently.
/implement-spec
Implement the feature step by step based on those tasks.
/code-review
Ask AI to review the implementation, then do a final manual review myself.

I have found this workflow surprisingly comfortable.

It reduces the amount of improvisation during implementation and gives the coding agent much clearer boundaries.

Letting `AGENTS.md` Accumulate Project Knowledge

One practice that has worked particularly well for me is asking AI to record mistakes, corrections, and project-specific rules in AGENTS.md.

Whenever something goes wrong, I try to convert that mistake into a reusable rule.

That gives future coding sessions access to the context accumulated from previous work.

Over time, the project starts developing its own operating manual.

This helps reduce repeated mistakes and makes future implementation more consistent.

The process becomes a kind of feedback loop:

Build → Find problems → Update rules → Build again

As the project's Harness becomes more complete, AI-assisted development also becomes much smoother.

For features that resemble something already implemented, a clear requirement and good task decomposition are often enough for the AI agent to handle most of the work.

I still review the result at the end.

Fully autonomous coding without verification is not something I am comfortable with yet.

The Token Problem

The biggest frustration during development has actually been Token limits.

I started with Cursor's $20 monthly plan.

I burned through the quota in roughly four days, mostly while using Grok.

After that, I switched to the $20 Codex plan.

The overall experience was decent, but I frequently had to wait around five hours for the usage quota to reset.

That interrupted the development flow more often than I expected.

I also used Tibo after its quota reset, but that still was not enough.

Later, Z Code gave users a huge Token allowance, on the order of hundreds of millions of Tokens.

There has been some controversy around it recently, but by then I had already used it extensively.

Eventually, I adjusted my workflow.

The current version looks like this:

Use GPT 5.6 or GPT 6 for requirement analysis, architecture, and task decomposition. Then hand clearly defined implementation tasks to lower-cost models such as GLM.

At first, I was skeptical about this setup.

I assumed that anything even moderately complex should be implemented by the strongest available model.

After trying it in practice, my view changed.

If the architecture has already been thought through and the tasks are broken into sufficiently small units, models such as GLM can handle a surprisingly large amount of real implementation work.

They perform especially well when:

The task boundaries are clear.
The expected behavior is explicit.
The implementation path is already defined.
The relevant project context is available.

For this type of task, the output is often good enough for my needs.

After eventually exhausting my Z Code quota as well, I subscribed to Command Code's $10 plan and started using DeepSeek 4.1 Flash more often.

Among Chinese models, the ones I currently find most practical for coding are GLM and DeepSeek.

They occasionally enter what I jokingly call "thunderous deep-thinking mode" and spend far too long reasoning about a very simple problem.

Still, their coding ability is already quite solid.

One small lesson from my own usage:

Start with the reasoning level set to "High." Unless the task is genuinely difficult, there is usually little reason to leave it on "Extra High" all the time.

Expensive Models Do Not Need to Do Everything

One of the biggest changes in my AI coding workflow has been realizing that the most expensive model does not need to handle every task.

A stronger model can focus on:

Requirement analysis
Architecture
Technical design
Edge cases
Task decomposition

Then a lower-cost model can handle:

CRUD implementation
UI adjustments
API wiring
Repetitive refactoring
Well-defined feature work

This creates a fairly practical division of labor.

You get the reasoning quality of stronger models where it matters most, while keeping Token costs under control during implementation.

For a solo developer, that balance can make a significant difference.

Learning SEO Along the Way

Recently, I have also been spending more time learning SEO.

Before building this project, my understanding of SEO was fairly shallow.

I assumed that semantic HTML, good page titles, and a clean page structure covered most of the important work.

Once I actually started building a global tool site, I realized there is much more to it.

For example:

Keyword research with tools such as SEMrush
Search volume analysis
Keyword difficulty analysis
Site architecture planning
Core keyword optimization
Long-tail keyword targeting
Content planning
Continuous page optimization

Ultimately, all of this has the same goal:

Increase the site's visibility in search engines.

When someone searches for a problem related to your product, you want your site to appear as high as possible in the results.

That gives you a chance to turn search traffic into:

Search → Click → Visit → Sign up → Use → Pay

I am still very early in this process, so I am learning as I go.

Final Thoughts

That is where the project stands for now.

My main goal with this post was to document what it looks like to start building a global SaaS tool from scratch as a solo developer.

The infrastructure is cheap.

Deployment is easy.

AI can already take over a meaningful amount of implementation work.

The harder part is gradually building a workflow that makes all of those tools work together reliably.

For me, that currently means:

Research → Design → Spec → Tickets → Implement → Review → Update AGENTS.md → Repeat

I am still learning, especially when it comes to SEO, distribution, and turning the project into something that consistently attracts users.

If I discover anything useful along the way, I will keep sharing what I learn.

Try it
Free account with starter credits, no card required: musictool.tools

Welcome to give me feedback on any suggestions for improving the website.👏

Does Your Website Need a Complete Rebuild, or Just Incremental Fixes

Thu, 01 Oct 2026 11:01:22 +0000

Deciding something needs to change is the easier decision. The harder one, and the one that actually determines cost and timeline, is whether that change is a handful of targeted fixes or a genuine rebuild from the ground up. Getting this wrong in either direction wastes real money, patching around a fundamentally broken foundation, or rebuilding something that only needed a few specific repairs.

The Real Question: Is the Problem in the Foundation or on the Surface

This is the actual distinction worth making before anything else. A surface problem, outdated visual design, a few confusing pages, missing content, sits on top of a foundation that's otherwise sound and can genuinely be fixed without touching that foundation. A foundational problem, an outdated platform that can't support current needs, a fundamentally broken information architecture, technical debt so deep that every small change requires disproportionate effort, isn't something targeted fixes can actually resolve, since the fixes themselves keep running into the same underlying limitation.

Signs Incremental Fixes Genuinely Make Sense

The core technical foundation is sound, and specific things need improvement. If the platform, hosting, and overall structure work well, but visual design feels dated, a few pages underperform, or specific content needs updating, targeted work addressing those specific things is genuinely sufficient.

Most of the site is actually working, with a few isolated weak points. A site converting reasonably well overall with one or two specific underperforming pages, a checkout flow, a pricing page, is a strong candidate for focused fixes on exactly those pages, not a full rebuild of everything already working.

The changes needed are additive, not structural. Adding a blog, a new feature, a new page type, to a platform that genuinely supports that kind of addition without a fight is incremental work, even if it's a substantial addition on its own.

Budget and timeline genuinely favor a faster, lower-risk path, and the underlying foundation can actually support what's being asked of it without compromising the result.

Signs You're Actually Looking at a Rebuild

The platform itself can't do what the business now needs, regardless of how it's configured. If the actual limitation is architectural, a platform that fundamentally cannot support the functionality or performance now required, no amount of targeted fixing changes that ceiling.

Every small change requires disproportionate effort or breaks something else. A site where adding one new feature reliably breaks two unrelated things, or where a simple content update requires touching code in several unrelated places, has accumulated enough technical debt that continued patching becomes genuinely more expensive over time than starting clean.

The fundamental structure, information architecture, navigation logic, doesn't match how the business or its customers actually work anymore. A site built around a business model or customer journey that's since changed substantially often needs restructuring at a level targeted fixes can't reach without essentially rebuilding the same portions anyway.

Multiple, compounding issues exist simultaneously. One or two isolated problems favor targeted fixes. A genuine cluster, real performance problems, a platform ceiling, an outdated information architecture, and significant accumulated technical debt all present together, tends to favor a rebuild, since fixing each individually often costs more in total than addressing them together from a clean foundation.

The Cost Comparison That Actually Matters

This isn't simply "rebuild costs more than fixes," though it often does upfront. The real comparison is the total cost of continued patching over a realistic time horizon versus the cost of a rebuild that resolves the underlying issue once. A foundation with genuine, structural problems tends to generate a steady stream of "small" fixes that each individually seem reasonable, but collectively, over a year or two, can exceed what a proper rebuild would have cost, while still leaving the underlying limitation unresolved the entire time.

A Practical Way to Decide

List every specific issue currently being addressed or considered. For each one, honestly assess whether it's a surface issue, fixable in isolation, or whether it traces back to the same underlying foundational limitation as several of the others. If most of the list traces back to one or two shared root causes, that's a real signal pointing toward a rebuild, even if each individual item, looked at alone, seems like a reasonable, isolated fix.

Why This Decision Shouldn't Be Made From Fear of Rebuild Cost Alone

Avoiding a genuinely necessary rebuild purely because of the upfront cost, while continuing to fund an ongoing stream of patches against a fundamentally limited foundation, often costs more in total and produces a worse result than committing to the rebuild would have. This is worth being honest about even when the rebuild number feels uncomfortable, since the real comparison is against continued patching costs over time, not against doing nothing at all.

Frequently Asked Questions

Can a rebuild happen gradually, or does it need to be all at once?
In many cases, a phased approach is genuinely possible, rebuilding the most critical or highest-impact sections first while the rest of the site continues running on the existing foundation, rather than requiring a single, large cutover. This depends heavily on the specific site's structure and what's actually driving current traffic and revenue.

How do I know if my technical debt is bad enough to justify a rebuild?
A useful practical test, covered in more depth in an earlier post on signs you need a redesign, is whether adding or changing things has become disproportionately difficult relative to how simple the change sounds in concept. Frequent, significant friction on changes that should be simple is a strong, concrete signal, more reliable than a general feeling that the codebase "seems old."

Is it ever worth rebuilding even if the current site is technically working fine?
Yes, if the current foundation genuinely can't support where the business needs to go next, even a currently-functioning site can represent a real, growing constraint worth addressing proactively, rather than waiting until it becomes an active, urgent problem.

If you're trying to figure out whether your own situation calls for a rebuild or targeted fixes, I'm happy to take a look and give you an honest, specific recommendation.

Get in touch: https://pixelanas.com/contact

Anas, full-stack Next.js developer building SaaS products and premium templates. X: @ASheikh69751

How to Turn Blog Posts into Pinterest Pins That Actually Drive Clicks

Wed, 30 Sep 2026 11:41:05 +0000

If the article is already live, Pinterest is a distribution layer — not a second blog. Each pin has to carry one angle from that page and send people to the same URL. Teams lose that when they treat pins as one-off graphics.

This piece first went live on pinops.app. I am syndicating it here so the workflow is easier to find on CoderLegion.

Why blog-to-pin workflows outperform one-off graphics

Your blog already has structure: headlines, sections, images, and a destination URL. Turning that into Pinterest pins is not about redesigning the article—it is about packaging clear angles that people want to save and click.

A strong blog-to-Pinterest system produces multiple pins per post (different hooks, crops, and board placements) while keeping copy honest and the destination consistent. See the complete Pinterest SEO guide for how those campaigns fit keyword research, boards, publishing and measurement.

That is core to how AI Designer approaches URL-based campaigns inside PinOps.

Extract pin angles from the article—not just the title

One blog post usually contains several save-worthy ideas. List the outcomes, steps, mistakes, and comparisons a reader might pin. Each angle becomes its own creative and title.

Primary promise: the main outcome of the post.
Step or list pins: numbered takeaways that scan well on mobile.
Myth vs reality or before/after framing when the content supports it.
Seasonal or niche variants when the same URL serves multiple audiences.

Design vertical creatives that match the destination

Pinterest is visual discovery. Use clear focal images, readable hierarchy, and templates that adapt to your headline—not static mockups that fight the copy. Browse niche-ready layouts in the template library, or refine details in Canva Studio.

Keep brand cues consistent across a campaign so saves feel familiar, but vary composition enough that the feed does not look like identical spam.

Write titles and descriptions that help discovery

Titles should state the benefit and include natural keywords people search for. Descriptions can expand with related phrases, without stuffing. For concrete patterns by niche, use our Pinterest pin title and description examples.

Alt text and on-pin text should match what the destination delivers. Misleading pins erode trust and waste impressions.

From URL to queue: a repeatable PinOps path

Operators who scale blog repurposing need a path from source URL → copy and creative → review → schedule. PinOps AI Designer is built for that loop: analyze the source, prepare editable copy, select design direction, then send finished pins into the publishing queue.

For setup, use the Getting Started documentation. When you have a larger URL list, pair the same review standards with CSV import.

Schedule the campaign—and keep a person in the loop

Once pins look right, schedule them with preferred slots and your posting window rather than dumping everything at once. Consistency helps; spam patterns hurt. See how to schedule Pinterest pins consistently and the publishing docs.

Every pin still needs a last check: creative, copy, board, and URL. That keeps the workflow usable and the brand safe.

Originally published at https://pinops.app/blog/turn-blog-posts-into-pinterest-pins.

About the author

Dalibor Belchevski is the founder of PinOps, building Pinterest creation, review and publishing tools for bloggers, affiliate publishers, online stores and agencies. He writes about Pinterest SEO, content workflows and building SaaS. Find more of his writing on DEV.

The Non-US Developer’s Guide to US LLCs: State Selection, Stripe & Compliance

Wed, 30 Sep 2026 10:52:41 +0000

For international developers building SaaS apps, Chrome extensions, or API services targeting Western markets, technical implementation is rarely the biggest bottleneck.

The real roadblock hits when you need payment infrastructure: integrating Stripe, onboarding with US neobanking rails, and protecting personal assets without paying exorbitant agency fees.

A US Limited Liability Company (LLC) remains the standard operational vehicle for non-US software founders. However, treating incorporation as a generic administrative task often leads to severe recurring costs and compliance penalties.

Here is an architectural breakdown of how international developers should structure their US entity in 2026.

1. The Cost Matrix: Why Bootstrappers Shouldn't Default to Delaware

Many agency services default international developers to Delaware. Unless you have signed term sheets from US venture capital funds that require a Delaware C-Corp transition, an LLC in Delaware introduces unnecessary balance sheet drag due to the mandatory $400 annual franchise tax.

Here is how the numbers actually compare over a 3-year holding horizon:

Jurisdiction	State Filing Fee	Annual Mandatory Fee	3-Year Baseline	Strategic Fit
Michigan	$50	$25 / year	$125	Lean solo developers minimizing fixed operating expenses
Wyoming	$100	$60 / year	$280	Developers prioritizing public anonymity and privacy
Florida	$125	$138.75 / year	$541	Commercial operations with East-coast physical presence
Delaware	$110	$400 / year	$1,310	Startups actively pitching institutional venture capital

Note: Calculations reflect mandatory state fees. A commercial registered agent (~$50–$100/yr) is required in all states for non-residents.

If your objective is purely running payment gateways and banking without overhead, Michigan ($125 over 3 years) and Wyoming ($280 over 3 years) offer significantly better unit economics.

2. The Critical Compliance Pipeline

Setting up the LLC paperwork is only stage one. International developers frequently stumble on three operational hurdles:

Step 1: Acquiring an EIN Without an SSN

Non-US citizens cannot use the IRS automated web portal. To obtain an Employer Identification Number (EIN):

Phone Application: Call IRS International Tax Operations at +1 (267) 941-1099 (Mon–Fri, 6:00 AM – 11:00 PM ET). Same-day issuance is possible if you call with Form SS-4 prepared.
Fax Routing: Submit Form SS-4 to +1 (304) 707-9471. Turnaround typically takes 4–7 business days.

Step 2: Neobanking Integration (Mercury / Relay / Airwallex)

Underwriters require:

Approved state formation certificate (Articles of Organization).
Official IRS CP575 confirmation letter (or 147C replacement).
A live operational landing page showing actual software terms, pricing, and clear company disclosure.

Step 3: The $25,000 Form 5472 Trap

This is where technical founders face severe risks. Foreign-owned single-member LLCs are classified as disregarded entities by the IRS.

Even if your software makes $0 revenue, any "reportable transaction" (such as wiring personal funds to fund initial server costs or registered agent renewals) triggers mandatory filing of IRS Form 5472 and pro forma Form 1120 by April 15.

The statutory penalty for failure to file starts at $25,000 per violation.

3. Master Reference Directory

To help international developers navigate state filings, compliance deadlines, and banking setups without paying thousands to middlemen, we consolidated a comprehensive open reference directory:

👉 Explore the Complete US LLC Formation & Compliance Hub

The hub contains step-by-step guides for all 6 major states, Form 5472 checklists, and IRS contact channels. Bookmark it for your project's operational planning.

Citevant AI Visibility

Tue, 29 Sep 2026 15:33:13 +0000

Citevant helps businesses track and improve their visibility in AI search. It monitors answers from ChatGPT, Gemini, Google AI Overviews, Perplexity and Claude, tracks competitor mentions and identifies the articles those engines cite. Citevant discovers relevant publisher contacts and sends personalized outreach requesting contextual brand mentions. Teams can follow visibility, outreach replies and Domain Rating from one dashboard.

Website: https://citevant.com

I built a lightweight React UI kit with a built-in licensing guard to monetize SaaS dashboards ⚡

Sun, 27 Sep 2026 06:43:47 +0000

Hey everyone 👋,

If your engineering team spends valuable sprint cycles building custom feature-gating logic (PRO vs ENT), token verification widgets, and telemetry status boxes every time you launch a new internal tool or customer-facing dashboard, we built something for you.

We just pushed @seosiri/developer-ui-kit v1.0.7 to the public NPM registry. It’s a lightweight, framework-agnostic white-label React UI kit designed specifically for software companies and indie teams building developer tools and SaaS dashboards.

Why Enterprise Teams Use It:

~Flexible Licensing Guard: Built-in cryptographic token validation (PRO / ENT) that locks or unlocks premium features instantly.
~Framework Agnostic: Pure React with zero bulky CSS baggage; compiles in seconds across Next.js, Vite, and Electron.
~Zero-Config Telemetry: Real-time edge latency monitors and one-click config generators out of the box.
~SEO & Compliance Safe: All outbound resources use strict absolute links and nofollow architecture.
Quickstart (1 Command):

The Math I Use to Decide If a SaaS Tool Is Actually Worth It

Thu, 24 Sep 2026 11:39:14 +0000

Every team building software ends up with the same recurring question: is this $15/seat tool actually paying for itself, or are we just used to having it around? Most of us answer that with a shrug and a Slack poll. I run SaaS Switcher, a site that tracks SaaS pricing and alternatives, and after reading enough vendor pricing pages I got tired of the shrug, so I put together a small ROI model and turned it into a free calculator.

Here's the formula behind it, in case you want to run it yourself or steal it for an internal tool:

```
monthly_cost = seats cost_per_seat
hours_saved_mo = seats hours_saved_per_user_per_week 4.33
monthly_value = (hours_saved_mo hourly_rate) + extra_revenue_per_month
monthly_net = monthly_value - monthly_cost

roi_percent = (monthly_net 12) / (monthly_cost 12) * 100
return_multiple = monthly_value / monthly_cost
```

4.33 is just weeks per month (52 / 12), which is the only slightly clever part. Everything else is arithmetic a spreadsheet could do, which is sort of the point: an ROI number is only as good as the two inputs nobody wants to estimate honestly, hours saved per user and the fully loaded hourly rate.

Worked example: 10 seats, $15/seat/month, 2 hours saved per user per week, $40/hour fully loaded rate, no extra revenue attributed.

Monthly cost: $150
Hours saved per month: 10 × 2 × 4.33 ≈ 86.6 hours
Monthly value: 86.6 × $40 = $3,464
Monthly net: $3,314
ROI: 2,209% (a 23.1x return)

That last number is why "is this tool worth it" conversations go badly without a formula. $150/month feels small enough to not scrutinize, and 2 hours/week/user feels small enough to round down to zero. Multiply them across a whole team and the answer usually isn't close either way, it's obviously yes or obviously no, and the model gets you there faster than a debate does.

Where this breaks: it's a directional model, not an audit. Hours saved and hourly rate are your own estimates, and if you fudge them the output just launders your bias into a percentage. The honest way to use it is to lowball hours saved and check whether the ROI still holds, not to hunt for the number that justifies a decision you already made.

I put this calculator together so nobody has to keep re-deriving it in a spreadsheet every renewal cycle: SaaS ROI Calculator. Seats, cost per seat, hours saved per week, hourly rate, optional revenue impact, monthly or yearly billing. Nothing goes to a server, your inputs stay in your browser's local storage, no account needed.

Curious how people here would model this differently, especially for tools where the "value" isn't hours saved but something fuzzier: fewer production incidents, faster onboarding, better retention. What would you add to the formula?

What Makes a Good SaaS Onboarding Flow (And Why Most Get It Wrong)

Thu, 24 Sep 2026 07:39:56 +0000

A landing page's job is getting someone to sign up. Onboarding's job is getting them to actually experience the product's real value before they lose interest, and this second job is where a huge share of otherwise promising SaaS products quietly lose the majority of the people who signed up.

Why Onboarding Matters More Than the Feature List

A new user who signs up and never reaches the moment where the product actually solves their problem for the first time almost never comes back to try again, they just quietly stop using it, no complaint, no feedback, just silence. This makes onboarding one of the highest-leverage things a SaaS product can get right, since it directly determines what percentage of paying-attention signups ever become real, active users in the first place.

The Core Job of Onboarding: Get to Value Fast

Every onboarding decision should be evaluated against one question, does this get the user closer to experiencing the product's actual core value, or does it delay that moment. A genuinely well-designed onboarding flow treats every additional step, every additional piece of required setup, as a real cost, since each one is another opportunity for a new user's attention and motivation to run out before they ever see what the product actually does.

Common Mistake: Requiring Too Much Setup Before Any Value Appears

A new user asked to configure a dozen settings, invite a full team, and complete an extensive profile before seeing anything the product actually does is being asked to invest real effort on pure faith, before earning any evidence the effort is worthwhile. The products that retain best tend to get a new user to a genuine, if simplified, taste of real value as fast as possible, sometimes even before requiring a full setup, then layering in more configuration once the user already has a reason to care.

Common Mistake: A Generic Tour Instead of a Real First Task

A guided tour highlighting every feature, delivered before a user has any actual context for why each feature matters, is information without motivation, and most of it doesn't stick. A more effective approach walks a new user through actually completing one real, meaningful task, not a tour of buttons, but genuinely doing the thing the product is for, since people remember and internalize what they actually do far better than what they're shown.

Common Mistake: Treating All New Users the Same

A user signing up because they're actively drowning in the exact problem your product solves has very different needs than one casually exploring options. Onboarding that asks a real, simple question upfront, what's your actual goal here, and adjusts the following steps accordingly, respects that difference, rather than forcing every new user through an identical sequence regardless of what they actually came for.

Common Mistake: No Clear Sense of Progress

A setup process with no indication of how many steps remain, or how close a user is to actually finishing, feels longer and more draining than the same process with a clear, visible sense of progress. Something as simple as a visible step counter or progress bar measurably affects completion rates, since uncertainty about how much effort remains is itself a real source of drop-off.

What Genuinely Good Onboarding Actually Looks Like

A clear, single next action at every step, never leaving a new user wondering what they're actually supposed to do right now.

Real progress toward an actual outcome, not just information delivery, a user should be doing the real thing, not watching a demonstration of it.

The absolute minimum required setup before first value, with anything non-essential deferred until after that first genuine "aha" moment has actually happened.

Contextual help exactly where confusion is likely, rather than a separate help section a confused user has to go actively search for.

A visible sense of progress and momentum, so the process feels like it's actively moving toward something, not an open-ended series of unclear steps.

The Difference Between Onboarding and a Tutorial

A tutorial teaches how to use a tool. Onboarding gets someone to an actual outcome. This distinction matters because the two easily get conflated, and a product with an excellent, thorough tutorial can still have genuinely poor onboarding if that tutorial teaches features in the abstract without ever getting the user to a real, meaningful result they actually wanted when they signed up.

Measuring Whether Your Onboarding Actually Works

The real metric isn't whether people complete the onboarding flow itself, it's whether they come back and use the product again afterward, genuine activation and retention, not just completion of a sequence of setup steps. A flow with a high completion rate and low return usage isn't actually working, regardless of how smooth the setup process itself feels.

Frequently Asked Questions

How long should SaaS onboarding actually take?
As short as it can genuinely be while still getting a new user to real value, there's no universal ideal length, since it depends entirely on the product's actual complexity. The real target is minimizing time to first genuine value, not hitting a specific number of minutes or steps.

Should onboarding be mandatory, or should users be able to skip it?
Allowing a skip option, while still making the guided path clearly the easier, faster route to real value, tends to work better than forcing every user through an identical sequence regardless of their own comfort exploring independently. Respecting that some users genuinely prefer to explore on their own, without treating that preference as a problem to prevent, avoids frustrating exactly the confident, engaged users who often become strong long-term customers.

Does onboarding matter as much for a B2B SaaS product as it does for consumer apps?
Yes, arguably more so, since B2B users often represent a genuine, harder-won opportunity, and losing them during onboarding is a more costly, harder-to-recover loss than a casual consumer signup. The same core principles, fast time to real value, clear next steps, minimal unnecessary friction, apply regardless of the specific audience.

If you're building a SaaS product and want a real, honest look at whether your current onboarding flow is actually getting new users to value fast enough, I'm happy to take a look.

Get in touch: https://pixelanas.com/contact

Anas, full-stack Next.js developer building SaaS products and premium templates. X: @ASheikh69751

Best Merchant of Record Providers for SaaS & eCommerce Businesses

Wed, 23 Sep 2026 07:25:47 +0000

In the changing world of SaaS and eCommerce, managing payments, taxes, and compliance across markets is becoming more complex. A solution that is gaining attention is the Merchant of Record (MoR) provider. This entity takes on legal responsibilities for transactions, billing, tax collection, fraud liability, and more. For businesses looking to simplify global commerce, using a MoR can support growth while reducing administrative tasks.

Below, we explore top Merchant of Record providers to know, starting with Gapp Group. We will look at their differences, how to select one, and common questions founders have before signing up.

Leading Merchant of Record Providers

Gapp Group
Gapp Group presents itself as a full-service MoR partner designed for SaaS and digital businesses. They manage checkout, local compliance, tax collection, and payouts for your operations. By working with a MoR like Gapp Group, you shift the legal and financial responsibilities of selling to them, allowing you to concentrate on product and growth.

Paddle
Paddle is popular in SaaS communities for combining subscription billing, localized checkout flows, and global tax compliance. Many businesses use Paddle to accept payments in various currencies. Paddle acts as the MoR and automatically handles VAT and sales tax obligations.

PayPro Global
PayPro Global provides MoR services specifically targeting sellers of software, SaaS, and digital goods. Their model focuses on compliance, handling multiple currencies, and addressing refunds, chargebacks, and payments, all in one place.

FastSpring
FastSpring is a well-known name in full-service eCommerce for SaaS and software. As a MoR, it manages taxes, local compliance, checkout, and global payments, so vendors do not have to deal with that complexity themselves.

Cleverbridge
Cleverbridge combines subscription billing with MoR capabilities, focusing on enterprise and mid-market SaaS providers. They prioritize global compliance, partner models, and flexible billing.

Nexway
Nexway serves as a MoR and eCommerce platform for digital goods and subscription businesses. They offer local payouts, various payment methods, and compliance in multiple jurisdictions.

These providers differ in pricing, industry focus, geographic reach, and levels of service. Choosing the right one depends on your business model, target markets, volume, and willingness to trade margin for convenience.

What a Merchant of Record (MoR) Does

A Merchant of Record provider acts as the seller on your behalf. While customers still see your brand, the MoR is legally responsible for payment processing, taxes, refunds, and compliance. Key functions include:

Tax & Compliance: Automatically calculating, collecting, remitting VAT, sales tax, or GST worldwide.
Risk & Fraud Management: Handling chargebacks, fraud detection, and refund policies.
Currency & Payment Methods: Enabling localized payments and currencies to increase conversions.
Checkout & Billing: Offering checkout flows optimized per region and managing subscription billing models.
Customer Support & Disputes: Acting as the merchant, the MoR handles payment disputes or chargebacks on your behalf.
By delegating these tasks, SaaS and eCommerce businesses avoid dealing with a maze of different tax laws and accounting obligations across regions.

How to Choose the Right MoR Provider
Here are key criteria to evaluate:

Geographic and regulatory coverage: Does the provider support the countries where your customers reside?
Fee structure and margin impact: Compare fixed fees, transaction percentages, and payout delays.
Support for your billing model: Does it support tiered, usage-based, or hybrid subscriptions?
Checkout flexibility & local payment methods: Ability to adapt checkout to local norms (wallets, bank transfers).
Customer experience & branding control: How much control you retain over invoice design, branding at checkout, etc.
Speed of payouts & currency conversions: Timeliness of remitting revenue to you.
Transparency and reporting: Quality of dashboards, analytics, and logs to monitor your business.
A MoR is not "free"; you pay for convenience and risk protection. However, for many growing SaaS and eCommerce companies, the relief from administrative and legal burdens makes it worthwhile.

Benefits & Trade-offs of Using a MoR

Benefits
Market expansion: You can sell globally without setting up legal entities in each country.
Compliance assurance: The MoR handles ever-changing tax laws, reducing your legal risk.
Simplified operations: One platform to manage subscriptions, refunds, and reporting.
Improved conversion: Localized payment methods and checkout increase customer trust.
Trade-offs / Considerations
Margin erosion: MoRs typically charge a commission, which can reduce your net revenue.
Less direct control: Since the MoR is legally the seller, some control over customer experience or policies may be constrained.
Dependence on MoR uptime and policies: If their system goes down, your sales may pause.
Transparency & data access: Some providers may limit you to aggregated data rather than full transaction logs.
Limited customization: For very specific business requirements, some MoRs may not support every intricacy.
A MoR is most effective when your business is expanding across many markets, and covering the operational costs of compliance becomes too expensive.

FAQs On Merchant of Record Providers
1. Why should a SaaS or eCommerce business use a Merchant of Record?
A MoR allows you to grow globally without setting up local legal entities in each market. They take on tax, payment, fraud, and compliance risks. For growing businesses, this saves time, legal costs, and operational challenges, so you can focus on your product and customer experience.

2. Will I lose my brand’s identity if I use a MoR?
Not necessarily. Many MoRs provide white-label or semi-branded checkout, invoice templates, and other customer-facing elements. Your brand stays visible while the MoR deals with the backend legal responsibilities. Always check branding control when choosing a provider.

3. How much does a MoR cost?
Costs vary significantly. Some charge a flat fee plus a percentage per transaction, while others have a higher commission for global coverage. The cost often reflects the complexity of the service, including the number of markets, currencies, tax jurisdictions, and fraud risks. Assess the total cost against the internal burden you would face.

4. Does using a MoR shift all liability away from my business?
No. A MoR takes on many legal responsibilities for financial and tax transactions, but your business still holds liability for the product, compliance, and contractual relationships. Be sure to read contracts carefully and understand which liabilities you still have.

5. Can I switch MoR providers later?
Yes, in most cases. However, migration might need data export, customer consent, updating checkout flows, and negotiating necessary payout or transition clauses. Plan transitions carefully and review onboarding costs before making a switch.

6. Which types of businesses benefit most from using a MoR?
Businesses with multi-market subscription models—such as SaaS, digital goods, marketplace platforms, and online learning—often gain the most. The more countries and revenue streams you handle, the more valuable a MoR becomes, making compliance and scaling easier.

Conclusion
As SaaS and eCommerce companies expand beyond borders, managing payments, tax compliance, and global customer expectations becomes increasingly challenging. Partnering with a strong Merchant of Record provider helps you reduce that complexity while maintaining growth and focus on your core value.

With options like Gapp Group, Paddle, PayPro Global, FastSpring, Cleverbridge, and Nexway, your choice will depend on your market coverage, billing flexibility, cost tolerance, and branding needs. Assess providers carefully, run trials, and select the one that matches your growth path.

By choosing the right MoR, you can confidently enter new markets, reduce legal risks, and offer seamless payment experiences, ensuring your business grows without being overwhelmed by administrative tasks.

EstateAI Create Property Guide: Upload Photos and Add Details

Mon, 21 Sep 2026 17:52:08 +0000

EstateAI Step by Step · Module 02: Properties · Guide 02.2

Earlier in the series: Part 01 — EstateAI Dashboard Explained

You have the property photographs ready. Before choosing an editing service, there is a more basic task: connect the right images to the right property.

The Create Property wizard is where this setup begins.

This guide follows the first two stages visible in the supplied EstateAI screenshots: Upload Photos and Property Details. It explains the available entry points, the upload status shown and the information to review before moving toward AI Analysis.

Guide scope: This is a screenshot-based walkthrough, not a recorded upload test. The later analysis, organisation and final-creation screens were not supplied. Client and property identifiers, source filenames and map details have been visibly redacted for publication; controls and workflow labels have not been recreated.

Quick answer

In the supplied interface, property creation follows this order:

Upload Photos → Property Details → AI Analysis → Review & Organize → Create Property

Start with the intended workspace and photo set. Inspect the upload information, add the relevant property details and check the location before using Next: AI Analysis.

Reaching Property Details does not mean the five-step creation process is finished.

Figure 1. The Property Details stage provides a view of the five-step wizard. The example is at Step 2, not the final creation confirmation.

1. Confirm where you are creating the property

The Properties screen covered in Guide 02.1 includes a New Property entry point. The screenshots for this guide show the setup screen titled Create Property.

At the top of the wizard, the banner reads CREATING IN — Personal Workspace. It states that the property will remain private to the user and use personal credits.

The Property Details screen also displays WORKSPACE LOCKED.

Read this context before adding the shoot. A property intended for a team should not be casually treated as a personal record without checking the selected workspace.

This screenshot does not show how to change the workspace during creation or explain the full permissions model. It also does not establish the cost of uploading, analysing or editing photographs.

Practical tip: Confirm the workspace before proceeding. Do not interpret “uses personal credits” as a price quote for a particular action.

2. Step 1: choose the property photographs

The first stage is titled Choose property photos first.

It presents a drag-and-drop area and a Select from Computer button. These are the visible local-file selection options.

The supporting text says uploading starts immediately while you complete property details. That describes the intended interface workflow; the screenshots do not measure upload speed or demonstrate what happens when a connection is interrupted.

Figure 2. A focused crop of the supplied upload screen. Surrounding capture overlaps have been excluded rather than reconstructed.

Prepare a coherent photo set

The source upload screen recommends high-resolution images, exterior photographs, important rooms and multiple room angles.

Our additional preparation recommendation is to check that the selected files belong to the same intended property and shoot. Keep a separate copy of the originals before using any editing workflow.

Do not add unrelated property images simply because they happen to share a folder.

The screenshot does not establish supported file extensions, maximum file size or a minimum pixel dimension. Follow the requirements actually shown by your account rather than assuming that every format is accepted.

Review action: Select the right source set first. Uploading more files is not the same as uploading the right files.

3. Understand the cloud-import options

Below the local upload area, an Import from section contains Google Drive and Dropbox controls.

The example also shows GOOGLE DRIVE CONNECTED.

That is a connection-status label in this account. It is not a demonstration of a successful cloud import, and it does not mean that every reader's Google Drive is already connected.

The accompanying text says imported photographs join the same upload and AI-analysis workflow as local files.

What the screenshot does not show

The provider file picker, permission request, folder-selection behavior and import-completion screen are not visible.

For a cloud-based shoot, inspect the account and files presented by the actual provider picker before confirming a selection. Do not assume that a connected-storage label means the required photographs have already reached EstateAI.

Practical tip: Treat connection and import as separate checks: the source account should be correct, and the selected files should appear in the property upload list.

4. Check the upload status in Step 2

The next supplied screen is titled Add your property details.

Above the form is a Photo uploads panel containing thumbnails, filenames and status labels. The visible example shows 39 of 39 uploaded, with Uploaded labels on the fully visible entries.

Figure 3. The upload count belongs to this example. It is neither a maximum allowance nor proof that analysis or editing is complete.

Read the count as upload progress for the displayed selection.

It does not establish that all 39 photographs were analysed, edited, grouped correctly or approved for delivery.

It also does not establish a 39-image limit.

The screen says uploads can continue in the background while details are being organised. The example itself shows a completed upload count; it does not demonstrate every possible pending or failed state.

Compare the upload list with the intended shoot

As a review step, compare the thumbnails and count with the files you meant to include.

A complete-looking counter can still accompany the wrong selection. The number alone does not tell you whether a bedroom was omitted or an unrelated exterior was included.

Review action: Check the identity of the photographs as well as their displayed upload status.

5. Add the property information

The form collects identifying details, location information and notes.

The table below preserves the visible field names. Its review advice is an editorial recommendation, not a description of hidden validation rules.

Figure 4. Field labels and the generic editing note are retained. Redaction blocks are publication edits, not native EstateAI field values.

Visible field	What to check before proceeding
Property Name	Use a clear name that distinguishes this record from other shoots.
Property Type	Confirm the selected type. Residential is shown here; other dropdown options were not captured.
Client Name	Check the intended client reference before associating it with these photographs.
Find property address	Inspect the location selected, rather than relying only on an address-like property name.
City, State, ZIP Code	Check these against the intended property location.
Country	Confirm that it is consistent with the address.
MLS Number	Check any identifier you enter; the screenshot does not prove MLS integration or validation.
Tags	The field displays example text, Luxury, New listing. Its exact parsing rules are not shown.
Notes	Record useful project context without assuming that this field automatically starts an edit.

The supplied image does not establish which fields are mandatory. Check the form's actual validation when using it; do not invent an MLS number or client detail just to fill an empty box.

Give the property a usable name

A hypothetical internal name such as Oak House — September Shoot is easier to distinguish than another Untitled property.

That is a naming suggestion, not a required format.

The property name and address are separate fields. A correct-looking name does not, by itself, confirm that the selected map location is correct.

6. Review the address and map together

The helper text beneath Find property address asks the user to choose the verified Google result.

A Property Location map appears beside the form in the supplied capture. It has been redacted in the public screenshot.

Review the address, city, state, ZIP code and country as one set. In your own account, also check whether the displayed map corresponds to the intended location.

Do not read the word “verified” as confirmation that every detail in the property record is correct. The screenshot shows a location-selection instruction, not an inspection of the property or a check of the uploaded photographs against the address.

This matters when similar street names or address-like text appear in different fields. Confirm the intended location rather than treating a populated map as the end of the check.

7. Use Notes for context, not an assumed generation command

The example Notes field contains:

Enhance and declutter etc

That records a broad editing intention. It does not demonstrate that the request has been submitted to an AI service.

A more specific note could help the person handling the job understand the brief. For example:

Example brief: Review the living-room photographs for enhancement. Any decluttering should remove only the named temporary items; retain existing furniture and permanent fixtures. Flag uncertain hidden areas before editing.

This is an editorial example, not a tested prompt or a claim that EstateAI interprets Notes in a particular way.

The service selection and settings should be checked in their own workflow. Do not treat a written note as evidence that images were processed, credits were charged or preservation instructions were automatically enforced.

8. Pause at “Next: AI Analysis”

At the bottom of Step 2, the screenshot shows Back and Next: AI Analysis.

The next button names the following stage. It is not the final Create Property action.

Before proceeding, use this short review:

Check	What you want to establish
Workspace	The record is being prepared in the intended context.
Photos	The displayed source set belongs to the intended property.
Upload status	You understand the state shown for your selected files.
Property details	Names, identifiers and notes are accurate where entered.
Location	Address fields and the map point to the intended place.

The remaining stage labels are AI Analysis, Review & Organize and Create Property.

Their actual screens were not supplied. This article therefore stops at the handoff to AI Analysis rather than claiming that analysis ran or a final property was successfully created.

Upload completion, analysis completion and final creation are different checkpoints.

Where the setup fits in the wider workflow

EstateAI by Pixel Perfects Solutions describes the property as the organising record for source images, client context, processing and versions in its product overview.

That is the product background for this setup: photos and identifying information need to refer to the same intended property.

When source photographs need professional correction, Pixel Perfects Solutions provides a separate Image Enhancement service, including white balancing, sharpening and perspective correction. That reference does not imply an automatic order or handoff from this creation screen.

For the development background, Dotera documents its work on the product in the EstateAI development case study.

These are first-party descriptions, not independent performance results.

Frequently Asked Questions

1. Do I upload photos or enter property details first?

In the supplied wizard, Upload Photos is Step 1 and Property Details is Step 2. This guide follows those screen labels. It does not assume that every product version presents an identical sequence.

2. Can I choose images from Google Drive or Dropbox?

Both options appear on the upload screen, and Google Drive is shown as connected in the example. The provider picker and completed import were not demonstrated, so account permissions and actual file selection must be checked in your session.

3. Does “39 of 39 uploaded” mean the photos are ready to deliver?

No. It reports the upload state shown for that selection. It does not prove that analysis, editing, review or final creation has finished, and it does not define a maximum photo allowance.

4. Is an MLS number required to create a property?

An MLS Number field is visible, but the supplied screens do not demonstrate its required/optional validation. Use a correct identifier where applicable and check the current form's requirements rather than inventing a value.

5. Will typing “enhance” in Notes automatically edit my photos?

The screenshot does not demonstrate that behavior. Notes should not be treated as proof of service selection, job submission or processing. Inspect the relevant service workflow before expecting an edited result.

6. What happens after Property Details?

The visible next action is Next: AI Analysis. The wizard then lists Review & Organize and Create Property. Their controls and results are outside the evidence available for this article.

Final takeaway

A useful property workspace starts before the first AI edit.

Select the right photographs. Check their upload status. Add a recognisable property name and accurate context. Review the location rather than trusting a filled field or map on its own.

Then move to the next stage with a clear understanding of what has—and has not—been completed.

Correct files, correct property, clear instructions: that is the foundation for the work that follows.

Next in the series: Guide 02.3 — AI Analysis, Review & Organize and the final creation screen.

Which setup check is easiest to overlook in your workflow: the photo selection, the address or the project notes?

Sources and screenshot notes

Figures 1–4 come from the two supplied Create Property screenshots. The upload figure is a focused crop because the original capture contains overlapping areas. No missing interface areas were reconstructed.

Client and property identifiers, source filenames and the map have been redacted. Field labels, workflow stages and displayed upload counts are retained. The screenshots' capture dates were not supplied.

The public workflow overview describes entering details before selecting photos in its summary. This guide does not silently reconcile that difference: it follows the supplied wizard, where Upload Photos comes first.

Public links were checked on September 21, 2026. The Properties app route required sign-in during verification; no upload, import, validation, analysis or billing action was performed in the account.

About the author

Waqas Ahmad writes for Pixel Perfects Solutions and supports its content, SEO and digital marketing efforts. His topics include real estate photography, AI, property-media workflows and PropTech.

Tyndall AI

Mon, 21 Sep 2026 10:41:55 +0000

Tyndall AI is an AI-native creative toolkit for image and video generation. Create images from text, turn prompts into cinematic videos, upscale images and videos, remove watermarks, and transfer motion from a reference video to a character.

Features: AI Image Generator, AI Video Generator, AI Motion Control, AI Upscaler, Video Watermark Remover. 10 free credits daily.

https://www.tyndallai.com

SnapVivid image-to-video studio

Sun, 20 Sep 2026 20:33:58 +0000

SnapVivid is an AI image-to-video studio. Start from a still photo, add motion, export a short clip for social drafts. No timeline editor.

Site: https://snapvivid.com/

Freemium. Built for creators who want a clip from one frame instead of a full NLE.

Modern SaaS & AI Content Workflow Tools: Best AI Copywriting and Content Workflow Tools for Bloggers

Sun, 20 Sep 2026 20:33:38 +0000

Blogging has changed considerably. Publishing a few articles each month is no longer enough for many websites competing for search traffic, newsletter subscribers, leads, and sales.

That workload is where modern SaaS and AI content tools can help.

The best tools are not necessarily the ones that generate the most words. A useful content workflow tool should reduce repetitive work while leaving the blogger in control of the ideas, facts, editorial decisions, and final publication.

Here are some of the strongest AI copywriting and content workflow tools bloggers can consider.

ChatGPT: Best All-Purpose AI Writing Assistant
OpenAI's ChatGPT is one of the most flexible options for bloggers because it can assist at several stages of the writing process. OpenAI's own guidance describes a practical workflow of planning, drafting, revising, and packaging content. ChatGPT can help develop article ideas, organize rough notes, create outlines, rewrite sections, adjust tone, and refine wording. OpenAI also recommends treating AI output as a draft that requires human review rather than as a final authority.

For bloggers, that makes ChatGPT particularly useful before and after the actual writing. You can use it to turn a broad subject into possible article angles, build an outline around a specific audience, identify questions readers may have, improve a draft, or create supporting material such as FAQs and social posts.

The main limitation is that a general AI writing assistant is not automatically a complete SEO workflow. Bloggers still need to verify facts, research search demand, assess competitors, and make their own editorial decisions.

Jasper: Best for Brand-Focused Content
Jasper is built heavily around marketing and brand content. Its blogging tools provide a document editor for writing, editing, and formatting, while its Brand Voice feature allows users to establish tone and formatting rules for AI-generated content. That makes Jasper more relevant to bloggers who publish as part of a broader marketing operation.

For example, a business blog may need articles, landing-page copy, promotional material, and other marketing content to maintain a consistent voice. Jasper can fit into that environment instead of being used solely as a basic article generator.

Jasper also supports integrations and collaboration features. Its official documentation lists integrations involving tools such as Zapier, Make, Google Sheets, Webflow, Google Docs, and Surfer SEO. For a solo blogger, that wider marketing focus may be more than necessary. For a content team or business publication, it can be more useful.

Surfer: Best for SEO Content Optimization
Surfer is particularly useful for bloggers whose main concern is search optimization. Its Content Editor analyzes ranking pages and provides recommendations concerning relevant terms, structure, and content coverage. The platform also provides optimization scores while an article is being developed.

Surfer's workflow extends beyond simply generating text. Its current Content Editor workflow includes research and outlining, writing and optimization, internal linking, pre-publication review, and publishing or exporting. Its Surfer AI product can also generate long-form articles based on search data, NLP analysis, and the target topic. The company states that generated articles can then be reviewed and refined inside the Content Editor.

This distinction matters. SEO software should not be treated as a substitute for editorial judgment. A high optimization score does not automatically make an article useful, accurate, original, or worth reading. For bloggers who already know how to write but want stronger SEO guidance, Surfer can be more valuable than a general-purpose AI writer.

Writesonic: Best for an Integrated AI and SEO Workflow
Writesonic combines AI writing with SEO tools, making it another option for bloggers who want more of the workflow inside one platform. Its current documentation describes an SEO Suite that includes keyword research, SEO optimization, and internal-linking capabilities. Its AI Article Writer also supports long-form article creation, with current versions offering features such as tone customization, internal linking, source citations, FAQs, and calls to action, depending on the plan.

Writesonic also has an SEO Checker and Optimizer that provides real-time content scoring and optimization options. That combination can be useful for bloggers who do not want to move constantly between separate applications for research, writing, and optimization.

The important point is that automation should not remove the research stage. AI-generated articles still require fact checking and editorial review, especially when an article contains statistics, product claims, financial information, legal information, or other details where accuracy matters.

Notion AI: Best for Content Planning and Organization
Notion takes a different approach. Instead of positioning itself primarily as an article-generation platform, Notion combines workspace organization with AI assistance. Notion AI can create outlines, brainstorm ideas, summarize pages, rewrite sections, adjust tone, and generate other content directly inside a workspace.

For bloggers, this can be valuable because content production involves more than writing. A blogger can maintain an editorial calendar, store article briefs, organize research, track drafts, maintain content guidelines, and manage publishing tasks in the same workspace. AI can then operate within that environment to help develop or revise individual pieces.

This is particularly useful when the main problem is not generating words but managing dozens of content projects without losing track of them.

What a Good AI Blogging Workflow Looks Like
Buying several AI tools does not automatically create an efficient content operation. The workflow matters more than the number of subscriptions.

A practical blogging process can look like this:

Research the topic: Start with the reader's problem and the information the article must provide. Verify important facts using reliable sources.
Build the article brief: Define the target audience, search intent, primary topic, supporting questions, desired length, and major sections.
Create the outline: Use an AI assistant such as ChatGPT or a content platform such as Surfer to organize the material. The blogger should make the final decision about what belongs in the article.
Write the draft: AI can accelerate first drafts, rewrite awkward passages, and help overcome blank-page problems. It should not be allowed to introduce unsupported facts simply because they make the article sound complete.
Optimize for search: This is where dedicated SEO tools can become useful. Surfer and Writesonic provide optimization features designed to assess content against search-related criteria.
Edit manually: Check every important claim. Remove repetition. Replace generic language with specific information. Add original observations, examples, experience, or reporting where appropriate.
Add internal links and supporting elements: Connect the article to relevant pages already published on the blog. Add FAQs, tables, images, calls to action, or other elements only when they serve the reader.
Publish and monitor: Publishing is not the end of the workflow. Review how articles perform and update useful content when information becomes outdated or the article no longer answers the searcher's needs.
Which Tool Should Bloggers Choose?
Choose ChatGPT if you want a flexible writing and brainstorming assistant that can work across many parts of the editorial process. OpenAI specifically positions it for drafting, revision, tone adjustment, brainstorming, and editorial feedback.
Choose Jasper if brand consistency and broader marketing content are central to your workflow. Its Brand Voice, collaboration, integrations, and marketing-oriented writing environment are designed around that use case.
Choose Surfer if SEO research, optimization, internal linking, and search visibility are the priority. Its Content Editor is specifically designed around research, optimization, review, and publishing workflows.
Choose Writesonic if you want AI article generation combined with SEO functionality in one platform. Its current tools cover article generation, keyword research, SEO optimization, and related search workflows.
Choose Notion AI if content organization is your bigger problem. Its strength is combining AI assistance with a workspace where bloggers can manage research, briefs, drafts, and editorial planning.
AI Should Speed Up the Workflow, Not Replace the Blogger
The biggest mistake bloggers can make with AI is measuring productivity by the number of articles generated. More content is not automatically better content.

A serious blogging workflow still requires topic selection, research, fact checking, editing, SEO judgment, and human oversight. AI tools are most useful when they remove repetitive work and give the blogger more time to concentrate on information, analysis, originality, and editorial quality.

The strongest setup may therefore be a combination rather than a single application. A blogger might use ChatGPT for brainstorming and drafting, Notion for editorial organization, Surfer for search optimization, or Writesonic for a more integrated AI and SEO workflow.

The right choice depends on where the bottleneck exists. If writing is slow, use AI to accelerate drafting. If organization is the problem, use a structured workspace. If search optimization is the weak point, use dedicated SEO software.

The objective is not to automate blogging completely. It is to build a repeatable content workflow that produces useful, accurate, search-friendly articles without turning the blog into a stream of generic AI text.

Your Business Is Actually Ready to Invest in a Custom Web App

Sun, 20 Sep 2026 09:50:25 +0000

Jumping into custom web app development before a business actually needs it is a common, expensive mistake, and so is waiting too long after the signs are already clear, stuck manually working around limitations that a real, custom solution would have already resolved. Here's how to actually tell which situation you're in.

1. You're Managing Core Operations Through Spreadsheets and Manual Processes

A spreadsheet is a genuinely fine tool right up until it isn't, tracking a growing amount of interdependent data, requiring manual updates across multiple people, prone to version conflicts and human error at a scale that starts costing real time and accuracy. If a spreadsheet has become a business-critical system that multiple people depend on daily, and it's visibly straining under that role, that's a real signal.

2. You're Paying for Multiple Disconnected Tools That Should Talk to Each Other

A business cobbling together several different subscription tools, manually re-entering the same data into each one because they don't integrate, is often looking at a cost, both in subscription fees and in manual labor, that a single custom system would meaningfully reduce, in addition to eliminating the errors that manual re-entry between systems reliably introduces over time.

3. Your Current Process Doesn't Scale With Growth

If handling twice the current volume, customers, orders, bookings, would require roughly twice the manual effort rather than the same team handling it more efficiently through better tooling, that's a real structural limitation worth addressing before growth actually forces the issue at an inconvenient moment.

4. You Have a Genuinely Unique Workflow No Existing Tool Handles Well

Most business needs are common enough that existing software, no-code tools, or industry-specific platforms already solve them well. When a business has a genuinely specific process, not just a preference, that doesn't map onto any existing tool without significant, awkward workarounds, that's a real signal the workflow itself might justify custom software built specifically around it.

5. Data Security or Compliance Requirements Exceed What Off-the-Shelf Tools Guarantee

For businesses handling sensitive data, healthcare information, financial records, anything with real regulatory requirements, generic tools sometimes can't provide the specific guarantees or audit capabilities required. Custom software built with those specific requirements in mind from the start can be the only realistic path to genuine compliance, rather than an inconvenient workaround layered on top of a tool that wasn't built for it.

6. You're Losing Real Revenue or Customers to Operational Friction

If customers are experiencing real friction, slow response times, errors, a confusing process, directly traceable to manual or poorly-integrated internal systems rather than the actual product or service itself, that operational friction has a real, measurable cost that a custom solution addressing the root cause can directly recover.

7. Your Team Is Spending Meaningful Time on Work Software Should Handle

If skilled team members are regularly doing repetitive, manual data entry or reconciliation work that a well-built system could automate entirely, that's not just an efficiency question, it's a real cost in what that team's time could otherwise be spent on, work that actually requires human judgment rather than administrative repetition.

When It's Genuinely Premature

You haven't validated that the underlying business idea or process actually works yet. Building custom software around a workflow that might fundamentally change once real usage reveals what actually works is expensive premature optimization, validating with simpler tools first, covered in more depth in an earlier post on SaaS idea validation, is usually the smarter sequence.

An existing tool or platform genuinely does handle your actual need well, even if it's not a perfect, ideal fit. "Not perfectly tailored" is a very different situation from "genuinely cannot support what I need," and a lot of businesses invest in custom software to solve the first problem when a better-configured existing tool would have been sufficient.

The cost of custom development would exceed the actual value of the problem being solved. A genuinely minor inefficiency, however annoying, doesn't always justify a real software investment if the actual cost of the current friction is smaller than the cost of a custom solution to fix it.

A Simple Way to Decide

Add up the real, concrete costs of your current situation, wasted time, lost revenue from friction, subscription costs for disconnected tools, errors from manual processes, as honestly and specifically as possible. Compare that honest number against a realistic estimate of what custom software would cost to build and maintain. When the current cost, compounding as the business grows, genuinely exceeds the investment required to fix it, that's a real, evidence-based case for custom development, not just a hopeful assumption that a nicer system would obviously be worth it.

Frequently Asked Questions

Can I start with a smaller, focused version of a custom app rather than building everything at once?
Yes, and this is usually the smarter approach regardless of how ready a business is overall. Building the single highest-impact piece first, the specific workflow causing the most real pain, validates the investment and produces real value faster than attempting to replace every existing tool and process in one large project.

How do I know if my business has outgrown a no-code tool specifically, versus needing fully custom development?
This is covered in more depth in an earlier comparison of no-code tools versus custom development, but the short version, recurring friction working around a no-code platform's specific assumptions, rather than working within them, is the clearest practical signal.

What's the risk of waiting too long to invest in custom software?
The main risk is that manual workarounds and operational friction tend to compound as a business grows, meaning the same underlying problem becomes more expensive and more disruptive to fix later than it would have been to address earlier, once more of the business's actual operations depend on the flawed current process.

If you're weighing whether your business has actually reached this point, I'm happy to give an honest, outside assessment of whether custom development makes sense for your specific situation right now.

Get in touch: https://pixelanas.com/contact

Anas, full-stack Next.js developer building SaaS products and premium templates. X: @ASheikh69751

AI Room Design Tool

Sun, 20 Sep 2026 07:23:35 +0000

About AI Room Design Tool

AI Room Design Tool is an intelligent interior design visualizer designed for homeowners, renters, real estate professionals, and interior decorators. Unlike generic AI art generators that invent fake windows or distort structural walls, the platform's signature "Keep Layout" mode preserves existing door swings, natural light, and walking clearances.

Users can effortlessly explore 12 curated interior aesthetics (including Japandi, Organic Modern, and Mid-Century), test flexible remodel depths from light decor refreshes to full renovations, and use the Point Edit brush to tweak specific furniture fabrics or wall paint.

Key Features

Photorealistic Renders: Convert actual photos into architectural design mockups in seconds.
Keep Layout Technology: Preserves room structure, windows, and doors accurately.
Shoppable Furniture Matching: Connects design concepts with real furniture pieces.
Freemium Access: Free starter credits on sign-up with no credit card required.

Website: https://airoomdesigntool.com

Multi-Tenant Architecture in Next.js 16 (2026)

Sun, 20 Sep 2026 03:02:16 +0000

Every SaaS product hits the same wall eventually: you built it for one company, and now you need it to work for a hundred — each with their own users, their own data, and their own little corner of the app, like acme.yourapp.com. Bolt that on badly and you get the nightmare scenario every backend developer fears: one bug in a WHERE clause, and Company A's customer list shows up in Company B's dashboard.

That's the entire problem multi-tenant architecture solves. It's not one trick — it's a set of decisions about routing, data isolation, and access control that, done right, make "which company does this user belong to?" a question your app can never get wrong, even if a developer forgets to ask it.

By the end of this guide, you'll have a working multi-tenant Next.js 16 app: subdomain-based routing through proxy.ts, a tenant data model backed by Postgres Row Level Security so isolation is enforced by the database — not just your application code — and a path to deploying it on Vercel with wildcard domains.

Quick Answer: What Is Multi-Tenant Architecture?

Multi-tenant architecture is a software design where a single application instance and (usually) a single database serve multiple independent customers — called tenants — while keeping each tenant's data, users, and configuration completely isolated from every other tenant. Instead of deploying a separate copy of your app per customer, one codebase and one deployment serve everyone, and the app itself decides which tenant a request belongs to and what data that tenant is allowed to see.

Think of it like an apartment building: one building (your app), many separate units (tenants), each with its own locked door (data isolation) — but the plumbing, the elevator, and the foundation (your codebase and infrastructure) are shared.

Single-Tenant vs. Multi-Tenant: The Difference That Matters

	Single-Tenant	Multi-Tenant
Deployment	One app + one database per customer	One app (usually one database) for all customers
Infrastructure cost	Scales linearly with customers	Shared, scales with usage not customer count
Data isolation	Physical (separate databases)	Logical (enforced in code and/or the database)
Updates/bug fixes	Deploy to every customer separately	Deploy once, everyone gets it
Customization per customer	Easy — each customer has an isolated deployment/configuration	Harder — needs a plan/feature-flag system
Best for	Enterprise clients needing full data isolation or compliance	SaaS products with many small-to-mid customers

Many collaboration and SaaS platforms expose workspace/organization concepts that follow the multi-tenant model. You don't get your own copy of Slack's servers when you sign up; you get a workspace, which is just a tenant inside their shared infrastructure.

💡 Tip: "Tenant" is deliberately generic — in your app it might be called a workspace, organization, team, company, or account. The underlying pattern is identical regardless of what you call it in your UI.

Why This Is Tricky

Multi-tenancy isn't hard because the concept is complicated — it's hard because the cost of getting it wrong is severe (a data leak between customers), and there are genuinely several valid ways to build it, each with real tradeoffs. Before writing any code, you need to answer two separate questions:

How do I identify which tenant a request belongs to? (subdomain, custom domain, or URL path)
How do I keep each tenant's data isolated? (separate databases, separate schemas, or one shared table set with a tenant_id column)

Get the first one wrong and tenants can't reach the right version of your app. Get the second one wrong and — worst case — tenants can see each other's data. We'll cover both, and this guide focuses on the combination most SaaS products actually ship with: subdomain-based routing plus a shared database with row-level isolation, because it's the cheapest to run and the fastest to build on, while still giving you database-enforced security.

The Three Data Isolation Models

Model	How it works	Isolation strength	Cost & complexity
Database-per-tenant	Every tenant gets a fully separate database	Strongest — physical separation	Highest — migrations, backups, and connections multiply per tenant
Schema-per-tenant	One database, one Postgres schema per tenant	Strong — separate tables per tenant	Medium — still need to manage N schemas, but one database to back up
Shared tables + `tenant_id`	One database, one set of tables, every row tagged with a `tenant_id`	Depends entirely on enforcement — weak if only in app code, strong with Postgres Row Level Security	Lowest — one schema, one migration, scales to thousands of tenants easily

For most SaaS products — and everything in this guide — shared tables with a tenant_id column, enforced by Postgres Row Level Security (RLS), is the right default. It's the cheapest to operate, the easiest to migrate, and — critically — RLS means isolation is enforced by the database itself, not just by remembering to add .eq("tenant_id", ...) to every query. Reach for schema-per-tenant or database-per-tenant only when a specific customer has a compliance requirement (like data residency) that a shared database genuinely can't satisfy.

Related: Supabase RLS Policy Generator — generates the exact kind of tenant-scoped policies this guide writes by hand, in seconds.

Three Ways to Identify a Tenant

Strategy	Example URL	Pros	Cons
Subdomain	`acme.yourapp.com`	Clean URLs, easy to brand, works great with wildcard SSL	Needs wildcard DNS + nameserver setup
Custom domain	`app.acme.com`	Best for enterprise/white-label, tenant owns their domain	Most setup work — DNS verification, SSL provisioning per domain
Path-based	`yourapp.com/acme/dashboard`	Zero DNS config, works anywhere immediately	Tenant is visible and editable in every URL, no per-tenant branding

This guide builds subdomain-based routing, since it's the sweet spot most SaaS products land on — better UX and branding than path-based, far less setup work than per-tenant custom domains. We'll touch on custom domains near the end for when you're ready to offer that too.

What We're Building

Next.js 16 with the App Router
TypeScript in strict mode
Supabase (Postgres) for the database, using Row Level Security for tenant isolation
Tailwind CSS for the (minimal) UI

By the end, visiting acme.localhost:3000 will resolve to Acme's tenant context, acme.yourapp.com will do the same in production, and every database query for tenant data will be protected by RLS — so even a bug in your own code can't leak one tenant's rows to another.

tenant1.yourapp.com/dashboard
        ↓
   proxy.ts resolves "tenant1" → looks up tenant in DB
        ↓
   Tenant ID attached to the request as a header
        ↓
   Server Component reads the header, fetches tenant-scoped data
        ↓
   Postgres RLS double-checks: is this row actually this tenant's?

Step 1: Project Setup

If you're starting fresh:

npx create-next-app@latest multi-tenant-app

Choose TypeScript, Tailwind CSS, App Router, and the src/ directory if you prefer it (this guide omits src/ for shorter paths). You'll also need Supabase:

npm install @supabase/supabase-js @supabase/ssr

Add your environment variables:

# .env.local
NEXT_PUBLIC_SUPABASE_URL=https://yourproject.supabase.co
NEXT_PUBLIC_SUPABASE_PUBLISHABLE_KEY=your_publishable_key
SUPABASE_SERVICE_ROLE_KEY=your_service_role_key

# The root domain your app is served from. In development this keeps
# its port (localhost:3000); in production it's your bare domain.
NEXT_PUBLIC_ROOT_DOMAIN=localhost:3000

⚠️ Common Mistake: SUPABASE_SERVICE_ROLE_KEY must never be prefixed with NEXT_PUBLIC_. It bypasses every Row Level Security policy in your database — treat it exactly like a database root password, server-only, never shipped to the browser.

Step 2: Resolve the Tenant in `proxy.ts`

In Next.js 16, the file previously called middleware.ts was renamed to proxy.ts — same job, same file conventions, just a new name and a change in default runtime (it now runs on the Node.js runtime by default, which matters here since we're making a database call on every request).

💡 Think of proxy.ts like a receptionist at the front desk of your building. Every visitor (request) talks to the receptionist first. The receptionist checks which company (tenant) they're visiting based on which door they walked through (the subdomain), confirms that company actually exists in the building directory, and then tells the elevator (your app) exactly where to send them — before the visitor ever reaches an office.

First, a small server-only lookup function:

// lib/supabase/service-client.ts
import "server-only";
import { createClient } from "@supabase/supabase-js";

// Service-role client — bypasses RLS, has no user session attached.
// Only ever call this for trusted, server-only reads like tenant lookups.
// Never import this into a Client Component.
export const supabaseAdmin = createClient(
  process.env.NEXT_PUBLIC_SUPABASE_URL!,
  process.env.SUPABASE_SERVICE_ROLE_KEY!
);

// lib/tenant/get-tenant-by-subdomain.ts
import "server-only";
import { supabaseAdmin } from "@/lib/supabase/service-client";

export type TenantSummary = {
  id: string;
  slug: string;
};

export async function getTenantBySubdomain(
  subdomain: string
): Promise<TenantSummary | null> {
  const { data, error } = await supabaseAdmin
    .from("tenants")
    .select("id, slug")
    .eq("slug", subdomain)
    .maybeSingle();

  if (error || !data) return null;
  return data;
}

If you already have Supabase auth wired up (see our Supabase Auth vs Firebase Auth guide if not), you likely already have these two files for keeping the auth session refreshed on every request:

// lib/supabase/proxy.ts
import { createServerClient } from "@supabase/ssr";
import { NextResponse, type NextRequest } from "next/server";

export async function updateSession(request: NextRequest) {
    let supabaseResponse = NextResponse.next({ request });

    const supabase = createServerClient(
        process.env.NEXT_PUBLIC_SUPABASE_URL!,
        process.env.NEXT_PUBLIC_SUPABASE_PUBLISHABLE_KEY!,
        {
            cookies: {
                getAll() {
                    return request.cookies.getAll();
                },

                setAll(cookiesToSet, headers) {
                    cookiesToSet.forEach(({ name, value }) =>
                        request.cookies.set(name, value)
                    );

                    supabaseResponse = NextResponse.next({
                        request,
                    });

                    cookiesToSet.forEach(({ name, value, options }) =>
                        supabaseResponse.cookies.set(name, value, options)
                    );
                    Object.entries(headers).forEach(([key, value]) =>
                        supabaseResponse.headers.set(key, value)
                    );
                },
            },
        }
    );

    await supabase.auth.getClaims();

    return supabaseResponse;
}

// lib/supabase/server.ts
import { createServerClient } from "@supabase/ssr";
import { cookies } from "next/headers";

export async function createClient() {
  const cookieStore = await cookies();

  return createServerClient(
    process.env.NEXT_PUBLIC_SUPABASE_URL!,
    process.env.NEXT_PUBLIC_SUPABASE_PUBLISHABLE_KEY!,
    {
      cookies: {
        getAll() {
          return cookieStore.getAll();
        },

        setAll(cookiesToSet) {
          try {
            cookiesToSet.forEach(({ name, value, options }) =>
              cookieStore.set(name, value, options)
            );
          } catch {
            // Ignore if called from Server Component
          }
        },
      },
    }
  );
}

⚠️ Don't skip this if you have authentication. Tenant resolution and session refresh are two separate concerns, but they both have to happen in the same proxy.ts run. If you only resolve the tenant and never call updateSession, Supabase's access token is never refreshed on the server, and signed-in users get logged out once it expires — even though nothing about tenant routing looks broken.

Now the proxy itself, composing both:

// proxy.ts
import { NextRequest, NextResponse } from "next/server";
import { updateSession } from "@/lib/supabase/proxy";
import { getTenantBySubdomain } from "@/lib/tenant/get-tenant-by-subdomain";

// Keep the port for building an absolute redirect URL later; strip it
// only when comparing hostnames.
const ROOT_DOMAIN_ENV = process.env.NEXT_PUBLIC_ROOT_DOMAIN ?? "localhost:3000";
const ROOT_DOMAIN = ROOT_DOMAIN_ENV.split(":")[0];

// Subdomains that belong to your main app, not a tenant.
const RESERVED_SUBDOMAINS = new Set(["www", "app", "admin", "api"]);

export async function proxy(request: NextRequest) {
  // Refresh the Supabase auth session first. This may rewrite Set-Cookie
  // headers if the access token needed rotating — we copy those onto
  // whatever response we ultimately return below.
  const supabaseResponse = await updateSession(request);

  const host = (request.headers.get("host") ?? "").split(":")[0];
  const subdomain = getSubdomain(host);

  // No subdomain, or a reserved one — this is the marketing site or the
  // main app shell, not a tenant. Nothing tenant-related to attach.
  if (!subdomain || RESERVED_SUBDOMAINS.has(subdomain)) {
    return supabaseResponse;
  }

  const tenant = await getTenantBySubdomain(subdomain);

  if (!tenant) {
    return redirectToTenantNotFound(request, subdomain);
  }

  // Strip any inbound tenant headers so a client can never forge them —
  // only this proxy is allowed to set x-tenant-*.
  const requestHeaders = new Headers(request.headers);
  requestHeaders.delete("x-tenant-id");
  requestHeaders.delete("x-tenant-slug");
  requestHeaders.set("x-tenant-id", tenant.id);
  requestHeaders.set("x-tenant-slug", tenant.slug);

  // Rebuild the response so the tenant headers ride along on the
  // *request* (this is what makes them readable via headers() in a
  // Server Component), then carry over any refreshed auth cookies.
  const response = NextResponse.next({ request: { headers: requestHeaders } });
  supabaseResponse.cookies.getAll().forEach((cookie) => {
    response.cookies.set(cookie);
  });

  return response;
}

// Redirects to the ROOT domain, not the unknown tenant's subdomain —
// redirecting back to the same bad host would just re-trigger this
// same lookup and loop forever.
//
// Built as a brand-new URL rather than mutating a clone of request.url.
// Cloning request.url first (new URL(request.url)) means the object
// starts out with the tenant subdomain already baked into it, and
// reassigning .host on that object is not reliable for fully replacing
// an existing hostname — in practice it can end up only changing the
// port and leaving the old subdomain in place (e.g. producing
// "unknowndomain.localhost:3000" instead of "localhost:3000"), which
// silently recreates the exact loop this function exists to prevent.
// Constructing the URL from a plain template string sidesteps that
// entirely, since there's no stale hostname left for anything to retain.
function redirectToTenantNotFound(request: NextRequest, subdomain: string) {
  const protocol = request.nextUrl.protocol; // "http:" or "https:"
  const notFoundUrl = new URL(`${protocol}//${ROOT_DOMAIN_ENV}/tenant-not-found`);
  notFoundUrl.searchParams.set("tenant", subdomain);
  return NextResponse.redirect(notFoundUrl);
}

function getSubdomain(host: string): string | null {
  if (host === ROOT_DOMAIN || host === `www.${ROOT_DOMAIN}`) return null;
  if (!host.endsWith(`.${ROOT_DOMAIN}`)) return null;

  return host.slice(0, -(ROOT_DOMAIN.length + 1));
}

export const config = {
  matcher: ["/((?!_next/static|_next/image|favicon.ico).*)"],
};

What's happening here:

updateSession(request) runs first and unconditionally — auth refresh shouldn't depend on whether the host happens to be a tenant subdomain.
redirectToTenantNotFound() builds a brand-new URL pointed at ROOT_DOMAIN_ENV (your real app domain) instead of the unresolved tenant subdomain. The next time proxy runs against that new URL, getSubdomain() returns null for the root domain and the request just passes through — no loop. This has to be a fresh URL, not a mutated clone of the incoming request's URL — cloning request.url first means the tenant subdomain is already baked into the object, and reassigning .host on it is not reliable for fully replacing that hostname (in practice it can end up changing only the port while the old subdomain silently survives, e.g. unknowndomain.localhost:3000 instead of localhost:3000), which just recreates the same loop this function exists to prevent.
The ?tenant= query param survives the redirect, so your /tenant-not-found page can show which subdomain didn't resolve.
We only build requestHeaders (and delete any inbound x-tenant-* values) once we know a real tenant was found — there's nothing to strip or attach on the reserved/no-subdomain path, since supabaseResponse is returned as-is.
supabaseResponse.cookies.getAll() returns whatever refreshed auth cookies Supabase's client queued up; copying them onto the new tenant-aware response means neither concern silently overwrites the other.

A minimal page for the redirect target:

// app/tenant-not-found/page.tsx
interface PageProps {
  searchParams: Promise<{ tenant?: string }>;
}

export default async function TenantNotFoundPage({ searchParams }: PageProps) {
  const { tenant } = await searchParams;

  return (
    <div className="mx-auto max-w-md space-y-3 p-8 text-center">
      <h1 className="text-2xl font-semibold">Workspace not found</h1>
      <p className="text-sm text-muted-foreground">
        {tenant
          ? `We couldn't find a workspace at "${tenant}".`
          : "That workspace doesn't exist."}
      </p>
    </div>
  );
}

⚠️ Common Mistake: Running your tenant lookup on the Edge runtime by explicitly setting runtime: 'edge'. Don't — proxy.ts in Next.js 16 runs on the Node.js runtime by default (and throws if you try to override it), which is exactly what you want here, since a database client typically needs Node.js APIs that aren't available on the Edge runtime.

💡 Tip: For a small application, this direct indexed lookup is straightforward. At higher traffic, cache the subdomain → tenant mapping in Redis/KV/Edge Config or another low-latency store so proxy doesn't hit Postgres on every request.

Step 3: Testing Subdomains Locally

You don't need to edit your /etc/hosts file for this. Modern browsers (Chrome, Firefox, Safari) automatically resolve any *.localhost address to 127.0.0.1 — it's a reserved TLD, not a Next.js feature. So once your dev server is running:

npm run dev

Visiting http://acme.localhost:3000 in your browser just works, as long as NEXT_PUBLIC_ROOT_DOMAIN=localhost:3000 is set in .env.local and a tenant with slug = 'acme' exists in your database.

💡 Tip: If a subdomain isn't resolving locally, it's almost always a browser/network quirk (some corporate VPNs or older browsers don't support .localhost resolution) rather than a bug in your code — try a different browser before debugging proxy.ts.

Step 4: Model Tenants and Isolation in Postgres

This is the part that actually keeps tenants' data apart. Run this in the Supabase SQL editor.

-- Core tenant table. The slug doubles as a DNS label (acme.yourapp.com),
-- so its constraint is stricter than a generic "url-safe string" check:
-- no leading/trailing hyphens, and capped at 63 characters (the DNS
-- label limit), on top of lowercase alphanumerics and hyphens.
create table public.tenants (
  id uuid primary key default gen_random_uuid(),
  slug text unique not null check (
    char_length(slug) between 1 and 63
    and slug ~ '^[a-z0-9-]+$'
    and slug !~ '(^-|-$)'
  ),
  name text not null,
  plan text not null default 'free',
  created_at timestamptz not null default now()
);

-- Who belongs to which tenant, and with what role
create table public.memberships (
  user_id uuid not null references auth.users(id) on delete cascade,
  tenant_id uuid not null references public.tenants(id) on delete cascade,
  role text not null default 'member' check (role in ('owner', 'admin', 'member')),
  created_at timestamptz not null default now(),
  primary key (user_id, tenant_id)
);

-- An example tenant-scoped resource — every real table in your app
-- (invoices, documents, tasks, whatever) follows this same shape.
create table public.projects (
  id uuid primary key default gen_random_uuid(),
  tenant_id uuid not null references public.tenants(id) on delete cascade,
  name text not null,
  created_at timestamptz not null default now()
);

-- The composite primary key (user_id, tenant_id) already gives Postgres
-- a btree index usable for "where user_id = ?" lookups, since a
-- multi-column index supports equality search on a leading prefix of
-- its columns — a separate single-column index on user_id would just
-- be a redundant duplicate. What that composite index can't serve
-- efficiently is "where tenant_id = ?" on its own, since tenant_id
-- isn't the leading column — that's the index actually worth adding.
create index idx_memberships_tenant_id on public.memberships (tenant_id);
create index idx_projects_tenant_id on public.projects (tenant_id);

alter table public.tenants enable row level security;
alter table public.memberships enable row level security;
alter table public.projects enable row level security;

What's happening here: tenants is your list of customers. memberships is the join table linking Supabase's built-in auth.users to tenants — one user can belong to multiple tenants (think: a consultant working with several client workspaces). projects is a stand-in for any real, tenant-owned data table — invoices, documents, tasks, whatever your app actually stores.

Write the RLS Policies

A tenant_id column on a table means nothing on its own — it's just data. Row Level Security is what turns that column into an actual security boundary, enforced by Postgres itself rather than trusted to every query you (or a future teammate) ever write.

-- Security-definer helper: returns every tenant_id the current user
-- belongs to. Wrapping it this way avoids the classic recursive-RLS
-- trap (a policy on "projects" querying "memberships", which has its
-- own RLS that would otherwise re-trigger the same check).
--
-- It lives in a dedicated "private" schema rather than "public" —
-- Supabase's Data API (PostgREST) only exposes schemas you've explicitly
-- opted into (public by default), so putting security-definer functions
-- in "private" keeps them uncallable directly over the REST/RPC API.
-- A security-definer function sitting in "public" is callable by anyone
-- who can reach your API, running with the *creator's* privileges —
-- that's a real privilege-escalation surface if it isn't locked down.
create schema if not exists private;

create or replace function private.user_tenant_ids()
returns setof uuid
language sql
security definer
stable
set search_path = ''
as \(
  select tenant_id
  from public.memberships
  where user_id = (select auth.uid())
\);

-- Postgres grants EXECUTE on every new function to PUBLIC by default —
-- revoke it explicitly, then grant only to the role that actually needs it.
revoke execute on function private.user_tenant_ids() from public;
revoke execute on function private.user_tenant_ids() from anon;
grant usage on schema private to authenticated;
grant execute on function private.user_tenant_ids() to authenticated;

-- Members can see their own membership rows
create policy "memberships_select_own"
on public.memberships
for select
to authenticated
using ( user_id = (select auth.uid()) );

-- Members can see the tenants they belong to
create policy "tenants_select_member"
on public.tenants
for select
to authenticated
using ( id in (select private.user_tenant_ids()) );

-- Members can only see, create, edit, or delete projects that belong
-- to a tenant they're actually part of
create policy "projects_select_tenant_member"
on public.projects
for select
to authenticated
using ( tenant_id in (select private.user_tenant_ids()) );

create policy "projects_insert_tenant_member"
on public.projects
for insert
to authenticated
with check ( tenant_id in (select private.user_tenant_ids()) );

create policy "projects_update_tenant_member"
on public.projects
for update
to authenticated
using ( tenant_id in (select private.user_tenant_ids()) )
with check ( tenant_id in (select private.user_tenant_ids()) );

create policy "projects_delete_tenant_member"
on public.projects
for delete
to authenticated
using ( tenant_id in (select private.user_tenant_ids()) );

What's happening here: user_tenant_ids() is a security definer function — it runs with elevated privileges internally, which lets it read memberships (bypassing that table's own RLS just for this lookup) without creating a circular dependency. set search_path = '' forces every identifier inside the function body to be fully schema-qualified (notice public.memberships, not just memberships) — without this, a malicious or accidental object created earlier in the search path could get resolved instead of the table you actually meant, which is exactly the class of attack Supabase's own linter flags as "Function Search Path Mutable." The revoke/grant pair closes the other half of the gap: by default Postgres lets any role call a newly created function, so without the explicit revoke, anon (unauthenticated requests) could call it too.

Every policy on projects then just asks "is this row's tenant_id one this user belongs to?" Wrapping auth.uid() in (select ...) lets Postgres cache the result once per statement instead of re-evaluating it for every row — a meaningful performance win once your tables have real data in them.

💡 Tip: Notice there's no policy granting using (true) anywhere. Every single operation is explicitly scoped to tenant membership — this is deliberate. A missing policy means Postgres denies access by default, which is exactly the fail-safe direction you want security to fail in.

⚠️ Common Mistake: Putting a security definer helper function in the public schema "because that's where everything else is." If a schema is exposed through Supabase's Data API settings (public is, by default), every function in it is a potential RPC endpoint — private (or any schema you deliberately keep out of the exposed-schemas list) is the safer default for anything that runs with elevated privileges.

Related: Supabase Auth vs Firebase Auth in 2026 if you haven't wired up authentication yet.

Step 5: Read the Tenant in Server Components

Now that proxy.ts attaches x-tenant-id to every request, build a small Data Access Layer function that reads it — this is the single place the rest of your app goes to ask "which tenant is this?"

// lib/tenant/get-current-tenant.ts
import "server-only";
import { cache } from "react";
import { headers } from "next/headers";
import { redirect } from "next/navigation";
import { supabaseAdmin } from "@/lib/supabase/service-client";

export type Tenant = {
  id: string;
  slug: string;
  name: string;
  plan: string;
};

export const getCurrentTenant = cache(async (): Promise<Tenant> => {
  const headersList = await headers();
  const tenantId = headersList.get("x-tenant-id");

  if (!tenantId) {
    // No tenant header means this request never went through a tenant
    // subdomain — proxy.ts only sets it for tenant*.yourapp.com traffic.
    redirect("/");
  }

  const { data: tenant, error } = await supabaseAdmin
    .from("tenants")
    .select("id, slug, name, plan")
    .eq("id", tenantId)
    .maybeSingle();

  if (error || !tenant) {
    redirect("/tenant-not-found");
  }

  return tenant;
});

What's happening here: headers() is async in Next.js 16, so it has to be awaited. Wrapping the whole function in React's cache() means no matter how many components on the same page call getCurrentTenant(), the actual header read and database lookup only run once per request.

Next, a helper that also confirms the signed-in user actually belongs to this tenant — not just that the tenant exists:

// lib/tenant/require-tenant-member.ts
import "server-only";
import { redirect } from "next/navigation";
import { createClient } from "@/lib/supabase/server";
import { getCurrentTenant } from "./get-current-tenant";

export async function requireTenantMember() {
  const tenant = await getCurrentTenant();
  const supabase = await createClient();

  const {
    data: { user },
  } = await supabase.auth.getUser();

  if (!user) {
    redirect(`/login?tenant=${tenant.slug}`);
  }

  // This query runs through the cookie-based client, so RLS applies —
  // it can only ever return a row for the signed-in user themselves.
  const { data: membership } = await supabase
    .from("memberships")
    .select("role")
    .eq("tenant_id", tenant.id)
    .eq("user_id", user.id)
    .maybeSingle();

  if (!membership) {
    redirect("/not-a-member");
  }

  return { tenant, user, role: membership.role };
}

Use it in a page:

// app/dashboard/page.tsx
import { requireTenantMember } from "@/lib/tenant/require-tenant-member";
import { createClient } from "@/lib/supabase/server";

export default async function DashboardPage() {
  const { tenant, user } = await requireTenantMember();
  const supabase = await createClient();

  // The explicit tenant_id filter selects the active tenant represented
  // by this request. RLS provides the database-level safety net that
  // prevents the signed-in user from accessing tenants they don't belong to.
  const { data: projects } = await supabase
    .from("projects")
    .select("id, name, created_at")
    .eq("tenant_id", tenant.id)
    .order("created_at", { ascending: false });

  return (
    <div className="mx-auto max-w-2xl space-y-6 p-8">
      <div>
        <h1 className="text-2xl font-semibold">{tenant.name}</h1>
        <p className="text-sm text-muted-foreground">Signed in as {user.email}</p>
      </div>

      <ul className="space-y-2">
        {projects?.map((project) => (
          <li key={project.id} className="rounded-lg border p-3">
            {project.name}
          </li>
        ))}
      </ul>
    </div>
  );
}

What's happening here: notice the .eq("tenant_id", tenant.id) filter is still there in the app code, even though RLS would block cross-tenant rows either way. This is defense in depth — the query filter makes the intent obvious to any developer reading the code, and RLS is the safety net that catches the case where someone forgets it.

Writing Tenant-Scoped Data with a Server Action

// actions/create-project.ts
"use server";

import { revalidatePath } from "next/cache";
import { createClient } from "@/lib/supabase/server";
import { requireTenantMember } from "@/lib/tenant/require-tenant-member";

export async function createProject(formData: FormData) {
  const { tenant } = await requireTenantMember();
  const supabase = await createClient();

  const name = (formData.get("name") as string | null)?.trim();

  if (!name) {
    return { error: "Project name is required." };
  }

  const { error } = await supabase
    .from("projects")
    .insert({ name, tenant_id: tenant.id });

  if (error) {
    return { error: error.message };
  }

  revalidatePath("/dashboard");
  return { success: true };
}

What's happening here: requireTenantMember() runs first, so an unauthenticated or non-member request never reaches the database at all. Even so, the insert explicitly sets tenant_id: tenant.id rather than trusting a value from the form — never let tenant identity come from client-submitted data, always derive it server-side from the resolved tenant context.

⚠️ Common Mistake: Accepting a tenantId field from formData or a request body and trusting it. The tenant a user is allowed to write to should always come from getCurrentTenant() / the resolved request context — never from anything the client sent.

Related: Role-Based Access Control (RBAC) in Next.js 16 pairs naturally with this — once you have tenants, you'll usually want owner/admin/member permissions within each tenant too, not just membership.

Step 6: Deploy Wildcard Domains on Vercel

To get acme.yourapp.com, beta-co.yourapp.com, and every future tenant's subdomain working automatically in production, you need a wildcard domain pointed at your Vercel project.

Point your domain to Vercel's nameservers (ns1.vercel-dns.com and ns2.vercel-dns.com). Vercel needs to control your DNS to automatically issue SSL certificates for each new subdomain.
In your Vercel project's Domains settings, add the apex domain: yourapp.com.
Add a wildcard domain: *.yourapp.com.

Once that's done, any single-label subdomain — acme.yourapp.com, beta-co.yourapp.com — automatically resolves to your deployment, with Vercel issuing a certificate for each one on the fly. No per-tenant DNS work required on your end.

⚠️ A wildcard certificate for *.yourapp.com covers exactly one DNS label — it matches acme.yourapp.com but not a deeper subdomain like docs.acme.yourapp.com. That kind of nested subdomain would need its own certificate and DNS entry, and this guide's getSubdomain() parser doesn't handle it either (it would slice docs.acme.yourapp.com down to the single string "docs.acme", which isn't even a valid slug under the constraint from Step 4). If you need per-tenant sub-paths like that, treat it as a separate, deliberate feature — don't assume it falls out of wildcard support for free.

Update your production environment variable to match:

NEXT_PUBLIC_ROOT_DOMAIN=yourapp.com

💡 Tip: If tenants will ever be able to publish their own content or run their own code on your subdomains (not just view data you control), submit your domain to the Public Suffix List so browsers isolate cookies between tenant1.yourapp.com and tenant2.yourapp.com. This matters more for user-generated-content platforms than a typical internal-dashboard SaaS.

⚠️ Important: If you become a platform that gives mutually untrusted customers control over content or code on separate subdomains, investigate whether your domain qualifies for the PSL PRIVATE section. This changes browser cookie boundaries, so understand the consequences before applying.

What About Custom Domains?

Letting a tenant use their own domain (app.acme.com instead of acme.yourapp.com) is a common upsell for higher-tier plans, but it's meaningfully more setup: you provision the domain onto your Vercel project programmatically (via the Vercel SDK), verify the tenant actually owns it with a TXT record, and let Vercel auto-issue SSL once verified. The tenant-resolution logic in proxy.ts from Step 2 extends naturally — you'd just add a lookup by full hostname (domain_${hostname}) before falling back to subdomain parsing. Treat this as a Phase 2 feature; ship subdomains first.

Production Checklist

[ ] proxy.ts deletes inbound x-tenant-* headers before setting its own — never trust client-supplied tenant headers
[ ] An unresolved tenant subdomain redirects to the root domain, not the tenant's own (bad) host — otherwise it loops
[ ] proxy.ts refreshes the Supabase auth session on every request, not just tenant headers
[ ] Every tenant-owned table has a tenant_id column, a matching index, and RLS enabled
[ ] RLS policies exist for select, insert, update, and delete — not just select
[ ] No policy anywhere uses a bare using (true) unless a resource is genuinely meant to be public
[ ] Server Actions derive tenant_id from the resolved server-side tenant context, never from client-submitted form data
[ ] Reserved subdomains (www, app, admin, api) are excluded from tenant resolution
[ ] Tenant slugs are constrained as valid single-label DNS names (no leading/trailing hyphens, ≤63 characters)
[ ] Wildcard domain (*.yourapp.com) and apex domain are both added in Vercel, with nameservers delegated
[ ] anon/authenticated table grants are explicitly restricted to only the operations the app requires

Wrapping Up

Multi-tenant architecture in Next.js 16 comes down to two layers working together: proxy.ts figures out which tenant a request belongs to and hands that context downstream as a header, while Postgres Row Level Security makes sure that context is actually enforced — not just trusted — every time data gets read or written. Get those two pieces right, and "which company does this row belong to?" stops being a question your application code has to get right on every single query; it becomes a guarantee your database makes for you.

From here, natural next steps are layering role-based permissions on top of tenant membership (owner vs. admin vs. member), building a tenant-scoped billing flow with Stripe subscriptions, and revisiting session vs. JWT if you want tenant context embedded directly in the session instead of resolved fresh on every request.

Continue Learning

Free Developer Tools

Supabase RLS Policy Generator — generate strict, tenant/team-scoped Row Level Security policies like the ones in this guide, including the auth.uid() performance wrapper and a security-definer helper function, without hand-writing SQL.

EstateAI by Pixel Perfects - Dashboard Explained: Credits, Properties, AI Outputs and Quick Actions

Fri, 18 Sep 2026 18:54:26 +0000

EstateAI Dashboard Explained: Credits, Properties, AI Outputs and Quick Actions

Part 1 of EstateAI Step by Step: learn how to read your workspace overview, return to recent properties, and choose where to begin.

EstateAI Step by Step · Part 01: Dashboard

You open EstateAI and see a credit balance, property cards, an AI-output count and several ways to start working.

Should you create a property, upload more photographs, open an existing result or check your available capacity first?

The Dashboard helps you choose that starting point.

This first guide in the EstateAI Step by Step series explains the Dashboard screen section by section. The goal is simple: understand what the screen is telling you before moving into a property or an editing workflow.

Guide scope: This walkthrough is based on an actual EstateAI Dashboard screenshot supplied for the series. The example account already contains work; it is not a fresh-account demonstration. Account values are illustrative, and button destinations were not tested for this article.

Figure 1. The supplied Dashboard view. The following close-ups are crops from this same screenshot, not separate processing tests.

Quick answer

The EstateAI Dashboard is an overview and navigation screen. In the supplied interface, it brings together your selected workspace, available credits, property usage, AI-output count, storage, recent work and shortcuts.

Use it to answer three questions:

Where am I working? What is shown for this account? What should I open next?

It is not, by itself, a quality review of your images. A visible output count or a setup-complete message does not demonstrate that every result has been checked or delivered.

1. Check your selected workspace first

The workspace selector sits near the top of the left sidebar.

In this example, it reads Personal Workspace, with the label PERSONAL · PRIVATE. A message beneath it states that personal properties and personal credits are active.

Figure 2. Check the selected workspace before interpreting the rest of the Dashboard.

This gives the figures and property entries a context. Before starting a task, confirm that the workspace shown is the one you intend to use.

The selector has a dropdown arrow, but its open menu is not part of the supplied Dashboard image. This guide therefore does not assume which alternative workspaces are available in the account.

Practical tip: Make checking the workspace name your first habit. Leave organisation switching and permissions for the dedicated Organisation guide.

2. Understand the four summary cards

The most prominent row contains Available credits, Properties, AI outputs and Property storage.

These are different measures. They should not be read as interchangeable indicators of progress.

Figure 3. The four cards describe the supplied account snapshot—not universal plan allowances.

Card	What this screenshot shows	How to interpret it
Available credits	0.5, with free plan beneath it	The displayed credit balance for this example.
Properties	4, with 4 of 5 used	The property count and usage indicator shown in this account.
AI outputs	1, with Across every property	The Dashboard's AI-output count, separate from the property count.
Property storage	705 MB, with Originals and generated media	Storage attributed to the media categories named on the card.

Credits are not a count of photographs you can finish

The screenshot shows 0.5 credits, but it does not show the cost of a selected service.

Do not turn that balance into a promise such as “you can process five more images.” The necessary service estimate is not on this Dashboard.

The practical next step is to check the relevant workflow and its displayed requirements before starting processing.

Properties and AI outputs answer different questions

This account shows four properties and one AI output.

There is no reason to expect those two numbers to match. One describes property records; the other describes outputs.

The output card also does not identify whether the result has been reviewed, selected for delivery or downloaded.

Storage is separate from credits

The storage card explicitly includes originals and generated media. The sidebar separately displays 705 MB / 11 GB.

That is useful account context, but it is not evidence that every plan includes 11 GB or that the displayed free-plan capacity will apply to another account.

Remember: Credits, property usage, output count and storage each need their own interpretation. None is a substitute for inspecting the work.

3. Choose between starting new work and continuing an existing property

Near the top-right of the main Dashboard area are two buttons:

View properties and Create property.

The Quick actions panel also contains New property, described as a way to start a property workspace.

These labels give you distinct starting choices. For a new property, look for the creation entry point. For an existing property, start with the property list or recent-work area rather than creating another record without checking.

This article identifies those entry points. The creation form, upload sequence and required fields belong in the next module.

Use “Continue working” to find recent entries

The large Recent work section is headed Continue working.

Each visible row includes a thumbnail, property name, descriptive status text, output count, displayed date and an arrow. A View all link appears above the rows.

Figure 4. Recent entries provide a starting point for returning to existing property work.

In this example, the first row shows one output, while the other visible rows show zero.

Those row-level details are more useful for choosing a property than relying only on the single total at the top of the Dashboard.

Practical tip: Use clear, distinct property names in your own workflow. When multiple entries have the same generic name, the thumbnail and other context become more important when choosing the correct record.

4. Use Quick actions to match the next task

The right-hand Quick actions panel presents four shortcuts with short descriptions.

Figure 5. The descriptions distinguish starting a property, choosing a treatment, adding media and opening saved outputs.

Quick action	Description visible in the interface	Starting purpose
New property	Start a property workspace	Begin a new property workflow.
AI services	Choose a transformation workflow	Find the relevant image-treatment workflow.
Upload photos	Add media to a property	Start the process of adding property photographs.
Review results	Open saved AI outputs	Move toward inspecting existing results.

The useful distinction is adding a source image versus reviewing an output.

If the next task is to examine an existing result, the review entry point is more relevant than beginning another upload. If the task is to add photographs, the upload entry point is the one labeled for that purpose.

These are interpretations of the visible labels, not a recording of what each button opens. Property selection, upload options and individual service controls will be documented in their own guides.

Keep source selection and result review separate

Before opening another generation workflow, decide whether you actually need another edit.

You may instead need to check an existing candidate or return to the correct property.

That is a recommended working habit—not an automated decision the Dashboard is shown making.

5. Read “Setup complete” in its actual context

Between the summary cards and recent work, the screenshot shows a banner with:

SETUP COMPLETE

Your EstateAI workspace is ready

The supporting text invites the user to review a result, download it or publish a share link. There is also an Open delivery button.

That is a visible next-action message. It is not proof that every property is finished.

Notice that the same Dashboard still shows draft in the descriptive text of recent property rows. The banner and the individual entries are not describing one identical status.

Treat these as separate questions:

Is the workspace ready to use?

What stage is a particular property at?

Has the exact image I intend to deliver been reviewed?

The Dashboard alone does not answer all three.

Review action: Before sending media to a client, inspect the relevant property and selected result. Do not use a general setup message as image approval.

6. Find plan information without guessing at allowances

The Dashboard contains several plan-related entry points.

The left sidebar shows Available Credits, a storage indicator and Manage Plan. Lower on the right, the Account health card shows free plan, the credit balance and Manage billing.

The main navigation also includes Billing.

These are useful places to identify where account and plan information is surfaced. However, the Dashboard screenshot does not show subscription options, service pricing, invoices or the result of opening those buttons.

For that reason, this guide does not turn the example figures into a pricing explanation.

Use the Dashboard to notice your displayed balance and usage. Use the relevant account details to establish what you can purchase or process.

The label Account health should also be read alongside its visible contents: here, it presents plan and credit information, not a technical audit of the account.

The left navigation lists:

Dashboard → Properties → AI Services → Merge to HDR → Projects → Favorites → Notifications → Organisation → Billing → Settings

In this screenshot, Dashboard is the selected item.

This is the main navigation for the series. Each major area deserves its own explanation rather than being compressed into a single introductory post.

For now, the important boundary is between the Dashboard overview and the individual property workspace where more detailed work is performed.

EstateAI's official product overview describes the broader platform around property records, source photos, processing, versions and delivery. That is product background; the screenshots remain the reference for the controls described in this guide.

The screenshot also shows notification indicators. Their appearance alone does not establish which events triggered them or whether every badge represents unread items. Notification types and actions belong in the Notifications module.

8. A simple routine for opening the Dashboard

Here is a suggested sequence based on the visible layout:

Confirm the workspace. Read the name in the selector before acting on the figures.
Check the four cards. Note credits, property usage, outputs and storage separately.
Decide whether the work is new or existing. Check recent entries before starting another property.
Choose the next task. Use the relevant entry point for property creation, uploads, services or review.
Inspect the actual work before delivery. A summary count is not a substitute for checking the chosen output.

This routine does not promise a particular processing result. It simply provides an orderly way to move from the overview to the appropriate task.

Where EstateAI, Pixel Perfects Solutions and Dotera fit

EstateAI by Pixel Perfects Solutions is the product covered in this series. Its published workflow guide describes connecting property imagery, processing, versions and delivery.

For professional visual-production services, Pixel Perfects Solutions offers Image Enhancement, including work such as white balancing, sharpening and perspective correction. This is a related service reference—not a claim that the Dashboard contains a tested one-click editing handoff.

For the development background, Dotera documents its design and development work on the platform in the EstateAI case study.

These are first-party references. The current article explains the supplied interface rather than independently evaluating the companies' performance.

Frequently Asked Questions

1. What is the EstateAI Dashboard used for?

The supplied Dashboard brings workspace context, account figures, recent property entries and quick actions into one screen. It helps you identify where to begin or resume work before entering a specific property or service.

2. Does every EstateAI account start with 0.5 credits and five properties?

The screenshot does not establish that. It shows 0.5 available credits and 4 of 5 properties used in one existing account. Do not treat its balance, usage limit or storage capacity as a universal new-account allowance.

3. What is the difference between credits and storage?

The interface presents credits as available for AI processing, while storage is shown in MB and GB for property media. They are separate measures. The Dashboard does not provide enough information to calculate a service's cost from the balance alone.

4. Why are the property count and AI-output count different?

They describe different things. The example contains four properties and one AI output. The Dashboard does not show the full history behind that difference; inspect the relevant property to understand its media and processing state.

5. Does “Setup complete” mean my images are ready to publish?

Not by itself. The banner says the workspace is ready and offers a delivery entry point. It does not demonstrate that each image has been checked, selected or approved. Review the actual result before using it.

6. Where should I start a new property or return to an existing one?

The Dashboard shows Create property near the top and New property under Quick actions. For existing work, it shows View properties, the Continue working rows and View all. The detailed property-creation process is the next guide's subject.

Final takeaway

The EstateAI Dashboard is most useful when you read it as a starting point—not as a verdict on the quality or completion of every image.

Confirm your workspace. Understand the four summary cards. Find the relevant property. Choose the next action. Then inspect the work in context.

Know the account context before starting a task, and know the result before delivering it.

Next in the series: Properties—finding existing workspaces and understanding the property-creation flow.

Which Dashboard detail would you check first: credits, storage or the property you last worked on?

Sources and screenshot notes

The five figures are one supplied EstateAI Dashboard screenshot and four unaltered-content crops from it. No interface elements were generated, renamed or redrawn.

Product and company background:

Guide prepared and public references checked on September 18, 2026. The screenshot's capture date was not supplied. Account figures and available controls may differ from those shown.

About the author

Waqas Ahmad writes for Pixel Perfects Solutions and supports its content, SEO and digital marketing work. His topics include real estate photography, AI, property-media workflows and PropTech.

5 Best Free QR Menu Makers (2026)

Thu, 17 Sep 2026 10:20:17 +0000

A QR menu should do more than open a static PDF. For a restaurant, café, bar, food truck, or hotel, it can become the entry point to a mobile menu, a table-aware ordering flow, pickup and delivery, multilingual content, and operational feedback.

The difficult part is choosing a platform whose starting plan matches the venue’s real needs. “Free” can mean a permanent operating plan, a short trial, or a limited freemium account with caps on menu items, QR codes, tables, or orders. Those are very different offers.

This plain-text guide compares five closely related products: MenuForma, MENU TIGER, OddMenu, FineDineMenu, and My Menu at MyDigiMenu.com. There are no tables in this version, so it can be pasted into editors that do not handle table formatting well.

The details below are a dated snapshot derived from the original comparison, which was published on August 31, 2026. Product limits, prices, regional availability, payment fees, and feature sets can change. Confirm the current terms directly with each provider before making a buying decision.

The short answer

For a business that wants to keep a complete digital menu online without first entering payment details, MenuForma is the most compelling starting point in this group. Its public Free plan is listed at $0 per month for one restaurant, with unlimited menu items and no credit card required. The same product can later support online ordering, table QR workflows, multiple languages, payments, custom QR codes, analytics, and multi-location management on eligible plans.

The other four products make sense in more specific situations.

MENU TIGER is the closest freemium alternative when a venue needs QR and online ordering immediately and can work within defined limits.

OddMenu is a lower-cost, display-focused option for operators who are comfortable starting with a free trial and then moving to a paid hosted menu.

FineDineMenu, now primarily presented under the FineDine brand, targets restaurants looking for a broader paid stack that includes AI-assisted menu work, analytics, marketing, customer relationship management, and reservations.

My Menu at MyDigiMenu.com is particularly relevant for tablet-heavy hospitality and hotel use cases, including table or room identification, reservations, currencies, and guest-management features.

First, distinguish a free plan from a free trial

A free trial answers one question: “Can we test the product before paying?” A permanent free plan answers a different question: “Can we keep this menu live in normal operations without a deadline?”

That distinction is important when a venue has a long menu, seasonal changes, several meal periods, a wine list, or many modifiers. A team that must either finish testing in two weeks or begin paying may not have enough time to assess the actual guest experience.

MenuForma’s public Free plan is positioned as a permanent entry point for one restaurant, with unlimited menu items and no credit card requirement. The public plan page shows that the Free tier begins with QR menu display and one primary language. The Regular plan is advertised from $9.90 per month and expands into features such as online ordering, table QR ordering, multiple languages, custom business information, custom food images, pickup and delivery, tablet mode, staff accounts, custom QR codes, analytics, and additional restaurants.

MENU TIGER also has a permanent freemium plan, but the original comparison recorded specific limits: one store, ten table QR codes, seven menu categories, seven food items per category, 200 QR orders per month, and 250 online orders per month. That can be useful for a small venue with a compact menu, but it is a different proposition from publishing an unlimited-item menu for one location.

OddMenu was listed as a one-month free trial rather than a permanent free tier. Its published entry price at the time of the original comparison was $10 per month, with lower effective monthly pricing for longer billing terms.

FineDineMenu and My Menu were also presented as trial-led products rather than permanent $0 operating plans. The original comparison listed FineDineMenu from $29 per month and My Menu’s StartUp plan from $39 per month. Treat those figures as historic reference points, not as a quote.

What each product is best at

MenuForma: a low-risk path from source menu to service workflow

MenuForma is built around the problem many restaurant teams start with: their menu already exists, but not in a format that is easy to use on a phone. The product states that users can begin with a PDF, photo, or website link, then create a digital menu, a QR menu, an online ordering page, and multilingual versions.

The platform supports several guest journeys. A per-table QR can identify the table for dine-in service. A unified QR gives customers an order number, which is useful for cafes, food courts, or counter service. Hotel and room-service QR codes can identify a room and allow scheduled delivery. There is also a shared-device tablet mode, a self-select mode where guests show a selection to staff without sending it to a backend, and a browse-only display-only mode.

This range matters because a QR code is not an operating model by itself. A fine-dining venue, a quick-service café, and a hotel may all use a QR code, but they need different context carried into the next step.

MenuForma’s strongest differentiator in this comparison is the adoption path. A venue can start by putting a complete menu online for $0, test the live guest flow, and decide later whether online ordering, multilingual menus, payment flows, analytics, reviews, or multi-location tools create enough value to justify an upgrade.

MENU TIGER: freemium ordering inside defined usage limits

MENU TIGER is a useful comparison point because its free tier is not only for menu display. At the time of the original comparison, it offered QR and web ordering capabilities within item, table-QR, and monthly-order limits.

The product was also noted for menu conversion, QR ordering, online ordering, kitchen-display workflows, modifiers, cash and Stripe payment options, feedback, translations, and selected integrations. The trade-off is the size of the free allowance. Its free plan may be a practical fit for a small operator that needs to test ordering immediately and has a short menu. It may be less suitable for a restaurant that needs to publish a larger catalog without managing hard menu-item limits.

OddMenu: straightforward display-first digital menus

OddMenu was positioned as a simple hosted digital QR menu. Its public feature set emphasized real-time updates, multilingual presentation, food photos, guest reviews, employee access, multiple venues, and unlimited scans.

For a business that primarily wants a clean, hosted menu and does not need a deeper ordering or payment workflow, that focus can be attractive. The main difference from MenuForma is the commercial model: OddMenu’s free access was a time-limited trial rather than an ongoing free operating tier.

FineDineMenu: broader paid restaurant growth tooling

FineDineMenu, now generally branded FineDine, goes beyond QR menus into a larger restaurant-operations and growth suite. The original comparison identified AI-assisted menu import, item descriptions and images, translations, order-and-pay, tablet menus, reservations, CRM, loyalty, analytics, menu engineering, marketing, and website creation among its stated capabilities.

That breadth can be valuable for a group that is already investing in marketing operations and wants a more extensive paid platform. The trade-off is a higher starting cost and no confirmed permanent free plan. In other words, FineDineMenu is a candidate when a restaurant needs a broad growth and operations stack, rather than only a low-risk way to publish a live digital menu.

My Menu: tablets, hotels, and room-aware workflows

My Menu, the product at MyDigiMenu.com, is an especially relevant alternative for hospitality businesses that need tablets or hotel-oriented workflows. Its public positioning includes QR and tablet ordering, table or room identification, reservations, pay-at-table, loyalty, CRM, feedback, chat, and order-status tools.

The original comparison also recorded support for more than 50 languages and more than 70 currencies. That combination can matter when a hotel or larger hospitality business has international guests and needs more than a single restaurant QR menu.

The associated trade-off is the higher paid starting point and the absence of a permanent free plan in the original comparison. It is best evaluated by a buyer whose primary requirements are tablet deployments, room service, reservations, currency support, and richer hospitality operations.

A practical way to choose

Do not start with a feature checklist. Start with the service model you must support on a normal busy day.

If the objective is to keep one complete menu live for $0, begin with MenuForma. Its permanent Free plan and unlimited menu-item allowance are the clearest fit for that requirement.

If the objective is to test QR and online ordering immediately within defined operational limits, consider MENU TIGER.

If the objective is a lower-cost paid digital display menu after a trial, look at OddMenu.

If the objective is a paid platform combining restaurant intelligence, AI-assisted marketing, CRM, menu engineering, reservations, and related operations, assess FineDineMenu.

If the objective is a tablet-forward hotel or hospitality deployment with room-aware ordering, reservations, currencies, and guest-management features, assess My Menu.

Treat the menu as structured, changing information

For developers and technical operators, the most useful framing is not “How do we generate a QR code?” It is “What is the source of truth for menu data, and how does it remain accurate across the guest journey?”

A printed PDF, a photo, or an existing webpage may be the source material. The guest-facing menu is a different layer: it must be readable on a phone, organized into useful categories, and aligned with the service process. Prices, availability, allergens, modifiers, and fulfilment instructions need a review path because they affect real orders.

A reliable workflow has four stages. First, import or structure the existing menu. Second, design the mobile menu so that a guest can quickly identify categories, items, prices, and choices. Third, select the right QR entry point for the service model: shared, per-table, counter-oriented, room-specific, or display-only. Finally, test the full scan-to-service journey using an actual phone before printing QR codes across the venue.

This is why the QR code should remain a stable entry point while the menu behind it stays editable. Reprinting materials after every dish, price, or seasonal change is unnecessary friction. The physical code can stay in place while the live information evolves.

Multilingual menus and ordering are operational choices

Translation is often presented as a purely promotional feature. In practice, it is an operating decision. A multilingual menu should improve comprehension without creating disconnected copies that staff struggle to maintain.

MenuForma publicly states that paid plans can support multiple languages and automatic menu translation in 70+ languages, while the Free plan includes one primary language. This can be useful for venues that serve international guests, but the restaurant should still own the final wording for high-impact information such as allergens, prices, availability, and service instructions.

The same principle applies to online ordering. Ordering is only helpful when the incoming order preserves enough context for the staff workflow. A table order should carry table context. A counter order may need an order number. A hotel order may need a room number and delivery timing. The platform choice should follow that context rather than treating all QR codes as interchangeable.

Final recommendation

For an independent restaurant, café, bar, food truck, or hotel that wants to start with a full digital menu before committing to a paid plan, MenuForma offers the strongest overall entry point in this comparison. The key advantage is not simply that it is free. It is that the free plan is positioned as an ongoing operating plan for one restaurant with unlimited menu items, rather than a short countdown or a reduced catalog.

The alternatives remain relevant when the business has different priorities. MENU TIGER is a credible freemium ordering option for a small menu and defined volume. OddMenu is a focused display-menu choice. FineDineMenu fits a broader paid AI and marketing stack. My Menu is a strong specialist option for tablet-heavy hotels and hospitality operations.

If you want to explore the MenuForma workflow, start at MenuForma. The current pricing and plan details are available on the MenuForma pricing page.

Building a QR Menu and Online Ordering Workflow with MenuForma

Thu, 17 Sep 2026 07:16:46 +0000

Restaurant ordering projects are often described as a QR-code problem: create a menu QR code, print it, and let guests scan. In practice, the harder engineering and product-design problem is keeping several things in sync: the source menu, the guest-facing interface, the ordering path, language choices, and the operational view used by staff.

MenuForma is built around that workflow. It lets restaurants, cafés, bars, and hotels turn a menu supplied as a PDF, image, spreadsheet, or webpage into a digital menu that can be shared through QR codes and used alongside online ordering. The product supports dine-in, pickup, delivery, and online-ordering scenarios.

This article is not an API tutorial or a claim about MenuForma’s internal architecture. Instead, it outlines a practical way for developers, product owners, and technically minded operators to reason about a restaurant ordering system: start with content as data, choose the right scan-to-service journey, and keep operational feedback close to the menu.

Treat the menu as a changing source of truth

The first product decision is not the QR code. It is deciding what counts as the authoritative menu source. A restaurant may begin with a PDF designed for print, a set of menu photos, a spreadsheet maintained by staff, or an existing webpage. These formats serve different workflows, but each can change when prices, availability, descriptions, or seasonal dishes change.

For that reason, a useful digital-menu workflow separates source material from the guest-facing menu. The source is what the business updates; the guest-facing menu is the version diners scan and browse. MenuForma accepts PDFs, images, spreadsheets, and webpage menus as starting points, which makes it possible to begin from the format a business already has rather than requiring a full menu rebuild on day one.

Workflow stage
Product question
Practical outcome
Intake
Where does the current menu live?
Preserve a clear source for items, prices, and descriptions.
Structuring
How should diners browse it?
Organize categories and item information for small-screen reading.
Distribution
How does a guest reach the menu?
Use a shared or table-specific menu QR code.
Service
What happens after browsing?
Match the path to dine-in, pickup, delivery, or online ordering.
Operations
How does the team learn from use?
Review orders and available menu, order, and sales insights.

The important design principle is simple: the QR code should be a stable entry point, while the menu behind it remains editable. Reprinting a code every time a dish changes creates avoidable friction. Maintaining one consistent access point while adjusting the live menu makes the physical and digital layers easier to operate together.

Design the scan-to-service journey before publishing a code

A menu QR code is an entry point, not the entire experience. Before distributing it, decide what a successful scan should enable at that venue. A quick-service café may want guests to browse, order, and collect. A full-service restaurant may want guests to scan a code associated with their table, then place a dine-in order. A hotel may need a menu that is easy to browse across multiple languages and service locations.

MenuForma offers both shared QR codes and table-specific QR codes, so the distribution model can reflect the operating context rather than a single generic flow. The distinction matters because the guest and staff contexts are different. A shared code is straightforward for a counter, poster, or social link. A table-specific code can preserve the table context for the dine-in flow.

When designing that journey, make the choices explicit. Is the QR code for browsing only, or should it guide a guest into ordering? Which service modes are enabled? What information does staff need when an order arrives? Clear answers prevent the common failure mode in which a polished digital menu exists but does not fit the venue’s actual service process.

Make mobile reading a product requirement

Most QR-menu sessions start on a phone, often with a guest standing at a counter or sitting at a table. That is why content structure matters as much as visual styling. Long text blocks, unclear categories, and inconsistent modifiers make a menu harder to use even when the QR code works perfectly.

For builders, a helpful mental model is to treat every dish as a small product record: category, name, description, price, and any customer-facing choice that needs to be understood before ordering. The objective is not to simulate a printed page inside a browser. It is to make the next decision obvious on a small screen.

This also creates a useful review loop. Before deploying a menu QR code widely, test the actual scan path on a phone. Check category navigation, item readability, the first action a user sees, and the path back to the menu. A link that functions technically can still produce a poor ordering experience if the information hierarchy is unclear.

Plan multilingual menus as an operating decision

Language is not only a translation feature; it changes the way a restaurant prepares content and serves guests. A restaurant that welcomes international diners needs descriptions and navigation that remain understandable without making staff manually duplicate every update.

MenuForma’s public plan information states that the Free plan supports one primary language, while paid plans can enable multiple languages at the same time and offer translation across more than 70 languages. That makes multilingual setup a deliberate product decision: choose a primary operating language, identify the guest languages that matter, and establish a review process for key wording such as dish names, allergens, and service instructions.

The responsible approach is to use translation to improve reach while preserving human ownership of customer-critical details. Pricing, availability, dietary information, and fulfilment instructions should always reflect the restaurant’s current operating reality.

Keep ordering feedback close to the menu

The value of a restaurant ordering system is not limited to the guest interface. Staff need a dependable way to receive and act on orders, while operators need visibility into how the menu performs over time. MenuForma lists real-time order notifications and menu, order, and sales insights among its product capabilities.

For a developer or product owner, this is where the workflow becomes operational rather than purely promotional. Questions such as these become useful:

•
Are guests reaching the right menu for the service context?

•
Which categories receive attention and which need clearer presentation?

•
Can staff identify new orders quickly enough to support the intended service flow?

•
Are menu changes reflected accurately before the next busy period?

The goal is not to over-instrument a restaurant. It is to give the team a practical feedback loop between menu changes, ordering activity, and day-to-day operations.

Use visuals to clarify dishes, not to replace accurate information

Food imagery can make a digital menu easier to browse, but it should not substitute for a correct description, current price, or real service expectation. MenuForma publicly lists AI-generated food images as a feature. In a thoughtful workflow, that capability is best treated as a visual aid: it can help create a more legible, coherent menu presentation while the restaurant remains responsible for the accuracy of the item details guests rely on.

This is an important distinction for any builder using generative tools in commerce. Images can support discovery and presentation, but they should not imply ingredients, portions, availability, or outcomes that the business cannot deliver.

A practical starting point

If you are designing or improving a QR-menu experience, begin with one real service path rather than trying to digitize everything at once. Choose a current menu source, structure the guest-facing version for mobile reading, decide whether the QR code is shared or table-specific, and test the exact journey from scan to order. Then add the operational loop: notifications for staff and a routine for reviewing menu and order signals.

MenuForma is intended to support this progression from existing menu material to a digital menu, menu QR code, and online-ordering workflow. To explore the product and its current capabilities, visit MenuForma.

Signs Your Business Is Actually Ready to Invest in a Custom Web App

Wed, 16 Sep 2026 08:32:07 +0000

1. You're Managing Core Operations Through Spreadsheets and Manual Processes

2. You're Paying for Multiple Disconnected Tools That Should Talk to Each Other

3. Your Current Process Doesn't Scale With Growth

4. You Have a Genuinely Unique Workflow No Existing Tool Handles Well

5. Data Security or Compliance Requirements Exceed What Off-the-Shelf Tools Guarantee

6. You're Losing Real Revenue or Customers to Operational Friction

7. Your Team Is Spending Meaningful Time on Work Software Should Handle

When It's Genuinely Premature

A Simple Way to Decide

Frequently Asked Questions

Get in touch: https://pixelanas.com/contact

Anas, full-stack Next.js developer building SaaS products and premium templates. X: @ASheikh69751

How to Audit a Forked SaaS Codebase Before You Build on It

Wed, 16 Sep 2026 05:29:18 +0000

The easiest part of forking a production SaaS is copying the repository. The dangerous part is assuming that a successful build means the new product has a clean foundation.

I learned this while turning an existing AI generation application into a second, image-first product. Authentication still worked. Uploads still worked. Credits, asynchronous tasks, provider submission, polling, and result storage were already there.

So were dozens of decisions that belonged to the first product.

The route tree described the old user journey. Navigation emphasized the old primary workflow. Shared-looking components imported page-specific data. Emails, examples, metadata, and tests quietly assumed that the first product's identity was still correct.

A fork preserves implementation and intent at the same time. Before adding features, you need to separate them.

This article presents the audit process I would use before building on any forked SaaS codebase.

A. Write the New Product Contract First

Do not begin by deciding which folders to keep. Begin by describing what the new product must mean to a user.

Write down:

the primary task;
the first public entry point;
the secondary workflows;
the inputs each workflow accepts;
the output users expect;
the capabilities that must remain operational;
the claims the new product must not inherit.

For my image-first product, the smallest public contract was:

Entry	Primary task	Accepted starting point
Homepage	Edit an existing image	Uploaded image plus prompt
`/image`	Generate or transform an image	Text or reference image
`/video`	Generate a video	Text or image

This table did more architectural work than a folder diagram. It made the product priority explicit and gave every inherited route something to be compared against.

Without a new contract, the fork will default to the old product's choices simply because they already exist.

B. Inventory the Public Surface Before the Shared Code

Developers often start an audit in lib, services, or components. I start with the public surface because routes reveal product ownership faster.

The first pass can be simple:

rg --files src/routes
rg --files src/pages
rg --files src/components
rg --files src/data
rg --files public

Adjust the paths for the framework, but keep the purpose of the pass: identify everything that teaches a user what the application is.

For each route, record its direct dependencies:

page blocks;
route-specific data;
messages and metadata;
media assets;
structured data;
tests;
navigation links;
sitemap and discovery entries.

Treat that collection as one vertical slice. A route is rarely just one file.

This prevents a common cleanup failure: deleting the page component while leaving its datasets, translations, tests, links, and assets behind. Those leftovers keep the old product alive as dead weight and make future searches misleading.

C. Search for Identity Leaks

The next pass looks for product identity outside the obvious brand configuration.

Search for the old:

product name;
domain;
email addresses;
CDN host;
storage prefixes;
database names;
route names;
model labels;
marketing phrases;
default workflow values.

Example:

rg -n -i 'old-product|old-domain\.com|support@old-domain\.com' .
rg -n 'video-model|image-to-video|old-workflow' src tests messages public

Do not blindly replace every result. Classify it.

Match type	Question	Typical action
Infrastructure identity	Does this select an environment or resource?	Move to the correct configuration source
Public product identity	Does a user see or receive it?	Rewrite for the new product
Historical test fixture	Does it describe a still-valid contract?	Keep only if the contract remains true
Provider identifier	Is it internal and required by an adapter?	Keep server-side and prevent client leakage
Obsolete feature reference	Does the new product still own this workflow?	Remove the entire vertical slice

The goal is not a zero-result search at any cost. The goal is to make every remaining result intentional.

D. Delete in Vertical Slices

Once the inventory is clear, remove irrelevant product slices before designing new abstractions.

For one old route, delete or update all of its connected pieces together:

route
├── page block
├── route data
├── messages
├── metadata
├── assets
├── tests
├── navigation link
└── sitemap entry

Then run focused checks.

rg -n 'removed-route|RemovedPage|removedMessageKey' src tests messages public
git diff --check

Use the project's real typecheck and focused test commands after confirming they do not start a browser, development server, or production build unexpectedly.

Deleting vertical slices first has an architectural benefit: it reduces the number of real consumers. An abstraction that appeared necessary with eight inherited pages may become unnecessary when only two valid consumers remain.

If you generalize first, you risk preserving requirements that the new product does not have.

E. Follow Failures Inward

Deletion will break things. That is useful.

Each failure tells you something about ownership:

A shared component fails because it imports route data.
A global navigation test fails because it assumes an old product page exists.
A generic generation control fails because its options come from a page-specific list.
A server module fails because a client-facing model name leaked into provider logic.

Do not repair these failures by immediately restoring the removed file or adding an optional flag.

Ask instead:

Was the deleted dependency a real capability?
Which layer should own the surviving fact?
Does more than one current consumer need it?
Can the dependency direction be reversed?

For example, a shared generation workspace should consume a model capability contract. It should not import the model list from a particular landing page. The landing page can select from the shared contract, but the shared contract should not know that the page exists.

This is where compile errors become more than errors. They expose the direction of dependency.

F. Trace One Complete Request

After removing the old public surface, trace one real operation through the system.

For an AI generation product, the path might be:

User input
   ↓
Public model selection
   ↓
Effective parameters
   ↓
Credit calculation
   ↓
Authenticated API request
   ↓
Task creation
   ↓
Provider adapter
   ↓
Polling or webhook update
   ↓
Result persistence
   ↓
History and result UI

At each step, ask whether the implementation depends on a stable capability or on the old product's presentation.

Stable capabilities often include:

access checks;
uploads;
credit decisions;
task states;
provider translation;
result storage;
failure recovery.

Product-owned decisions often include:

which models are promoted;
which controls appear;
page defaults;
examples and prompts;
navigation;
SEO copy;
visual hierarchy.

The same effective parameters must drive the visible controls, credit estimate, and server request. If those three derive from different sources, the fork has inherited a drift problem even if each path works independently.

G. Separate Similar Lifecycles Without Erasing Domain Differences

The original application already had a structured video runner and provider adapters. The image path needed a similarly explicit lifecycle before more image models and tools were added.

That did not mean combining image and video into one giant controller.

A useful boundary can look like this:

interface TaskAdapter<Request, ProviderTask, Result> {
  submit(request: Request): Promise<ProviderTask>;
  getStatus(task: ProviderTask): Promise<"pending" | "complete" | "failed">;
  getResult(task: ProviderTask): Promise<Result>;
}

interface TaskRunner<Request, Result> {
  run(request: Request): Promise<Result>;
}

This pseudocode describes the direction, not a required implementation.

Image and video can share task lifecycle behavior while retaining separate input types, capability rules, controllers, and workspaces. Symmetry is valuable where it prevents operational drift. It is harmful when it hides meaningful domain differences.

I applied this distinction while building PicVane, the image-first product that emerged from the audit. Its image editor, image generator, and video generator can present different workflows while relying on consistent task, credit, upload, history, and result behavior underneath.

H. Require Evidence Before Building a Multi-Product Framework

Two related products do not automatically justify a multi-brand runtime.

Before adding brand factories, route registries, deployment matrices, or universal page schemas, look for evidence such as:

repeated changes that must be ported in both directions;
the same deployment and database;
the same release cadence;
the same operational ownership;
three or more real consumers with stable shared requirements;
measurable maintenance cost caused by separate implementations.

Without that evidence, separate repositories plus narrow, explicit capability contracts may be cheaper.

The test is not whether two codebases contain similar files. The test is whether they must make the same decision for the same reason.

I. Verify Four Different Layers

A fork audit is not complete when the typecheck passes. Record what each validation layer actually proves.

Layer	What it can prove	What it cannot prove
Source	Imports, types, route registration, static contracts	Browser behavior or provider success
Focused tests	Specific ownership and lifecycle rules	Complete end-to-end behavior
Runtime	Pages load and interactions execute	Real external service outcomes unless tested
Product evidence	Users understand and use the new direction	Architectural correctness by itself

Keep these claims separate.

A clean source audit does not prove that provider calls, payments, emails, analytics, or generated results work in production. A successful runtime test does not prove that users want the product. A clean architecture makes learning safer and faster; it does not replace the learning.

Final Audit Checklist

Before adding major features to a forked SaaS, confirm that you can answer yes to these questions:

Is the new product's primary task written down?
Has every inherited public route been accepted or rejected intentionally?
Are old brand, domain, email, storage, and workflow references classified?
Were obsolete features removed as complete vertical slices?
Do shared modules avoid importing product-owned page data?
Does one capability source drive UI options, pricing, and server requests?
Are provider identifiers and secrets kept behind server boundaries?
Are different domains allowed to keep different types and controllers?
Is every new abstraction supported by current consumers rather than hypothetical ones?
Are source, test, runtime, provider, and market claims reported separately?

If several answers are no, adding features will make the inherited assumptions harder to remove.

The best time to audit a fork is before the new product looks busy. At that stage, deletion is still cheap, boundaries are still negotiable, and a smaller route tree can reveal what the system actually knows how to do.

Reuse the operational knowledge.

Re-earn the product decisions.

Disclosure: This article is based on my own implementation experience. AI was used to help organize the structure and edit the English draft; I reviewed the technical claims and final text.

I Tried Building Solo With AI Agents in 2026. Here's What Actually Held Up.

Thu, 10 Sep 2026 20:10:13 +0000

Hey everyone — this one's for the builders in this community who keep asking me "what's actually in your toolkit right now." I've been heads-down shipping side projects with AI coding agents all year, and 2026 has been the year the tools around the AI finally caught up to the AI itself. Not another chatbot. Actual infrastructure for people who are trying to ship real software, alone or in a tiny team, without a full engineering org behind them.
Here are the four tools I keep coming back to, in the order I actually reach for them when I start a new build.

Starting point: the coding agent itself — Kimchi

Most of my week still lives in a terminal coding agent, and lately that's Kimchi. What sold me isn't that it's "another Claude Code competitor" — it's genuinely different in how it thinks about cost. Instead of hammering one frontier model for every single task, Kimchi runs a multi-model orchestration layer: it looks at what you're asking for and routes it to the model that actually fits, saving the expensive frontier model for the genuinely hard stuff and letting cheaper open-weight models handle routine execution.

As a solo builder paying for my own tokens, this is the difference between a $40 debugging session and a $15 one. Kimchi also just went general availability with claims of about 2.5x lower cost than running commercial models only, and it added support for MiniMax M3 as a builder model, which has been noticeably fast on long, boring refactor tasks. There's also built-in budget governance — hard spend caps, automatic shutdown of runaway loops — which matters a lot more than I expected the first time an agent got stuck in a retry loop overnight.

Before I even open the terminal: BrainGrid

Honestly, my biggest failure mode this year wasn't bad code, it was bad specs. I'd describe something vaguely, the agent would build something, and three features later the whole thing would collapse under its own weight — conflicting logic, half-finished integrations, features that quietly broke each other.

BrainGrid is the tool I now run before I touch a coding agent. It acts like a product manager you don't have: it interviews you about what you actually want, asks the clarifying questions you didn't think of, and turns that conversation into a real spec — acceptance criteria, data model, a "readiness score" — before generating a sequence of small, hyper-specific tasks that a coding agent can execute one at a time without losing the plot. It's built by former Twilio engineers, raised a pre-seed round this year, and has already been used by 500+ solo builders and small teams to ship real, revenue-generating SaaS products, not just demos. For anyone in this community who's non-technical but has a product idea, this is genuinely the closest thing I've seen to "hire a PM for a few dollars."

Making sure it actually works: Maestro

Here's the thing nobody tells you about agent-built features: the agent will confidently tell you it's done. Whether the button actually works on a real device is a different question entirely. Maestro is how I close that gap. It's open-source, agentic UI testing for mobile and web apps, and it plugs directly into my coding agent through MCP — meaning my agent can literally look at the running app, tap through it, take screenshots, and write proper end-to-end tests in plain readable YAML.

I've had it catch things I would have shipped broken — a setting that didn't persist after restart, a screen that broke under a bigger font size for accessibility. It's free to run locally through the CLI or their Studio app, and there's a cloud tier if you ever need to run tests across a real device matrix instead of one emulator. For solo builders especially, this is the closest thing to having a QA person on staff.

Staying on top of it all: Git Digest

Last one, and it's less flashy but it's saved me real time: Git Digest. When you've got agents opening PRs across a few repos while you sleep, it's genuinely hard to keep a mental model of what actually changed. Git Digest reads your GitHub activity and sends a plain-English summary — daily or weekly, by email or Slack — that tells you what shipped, what got fixed, and what's trending in terms of velocity and "hotspot" files that keep needing rework.

I mostly use it as a gut check before I look at anything else in the morning: did anything weird happen overnight, is one part of the codebase getting touched way more than it should. It's a small habit but it's replaced what used to be me anxiously scrolling through commit history with coffee.

The honest takeaway

None of these four things are hype products. They're all solving a genuinely boring, unglamorous problem: making AI-built software not fall apart. If you're building solo or in a small team in 2026, my honest advice is start with the plan (BrainGrid), pick a coding agent that doesn't bankrupt you (Kimchi), verify what it actually built (Maestro), and stay aware of what's happening across your codebase (Git Digest). Happy to go deeper on any one of these in a future post if people want it — just drop a comment.

The Unseen Work Behind Building a SaaS

Wed, 09 Sep 2026 05:00:05 +0000

I've been quieter on CoderLegion for a little while.

Not because I ran out of things to write about. Quite the opposite.

I've been spending a lot of time building Dulvarn, and one thing I've been learning as a solo founder is that a surprising amount of product work doesn't look like product work from the outside.

You can spend days working on infrastructure, CI, security, project rules, or deployment processes and have very little new UI to show for it.

It's still important work.

But it also raises a difficult question:

How much time should you spend making the foundations better before you get back to building what users actually see?

I'm still learning how to answer that.

The part of SaaS building that doesn't make a good screenshot

When people imagine building a SaaS, they often picture the visible parts.

A landing page. A dashboard. A new feature. A product demo. A first customer.

Those are the exciting milestones.

But behind them there is another layer of work.

Development environments. CI pipelines. Infrastructure. Secrets. Deployment configuration. Database migrations. Monitoring. Security. Documentation. Rules for how the codebase is maintained.

None of those automatically creates customer value on its own.

But when they're missing or unreliable, they can make every future change slower and riskier.

Recently, a lot of my attention has been on that less visible layer of Dulvarn.

Why I started taking the internal setup more seriously

Dulvarn is not a single small application anymore.

There is a backend, a web application, supporting tools, and AI-related components. They need to work together, and changes in one part can affect another.

As a solo founder, I don't have separate teams looking after infrastructure, backend, frontend, QA, and operations.

I have to make decisions across all of them.

That creates a temptation to solve problems quickly and move on.

A configuration works locally? Fine.

A pipeline passes? Great.

A deployment succeeds? Move to the next task.

But over time, small inconsistencies accumulate.

Different environments. Different assumptions. Different project rules. Different ways of running quality checks.

Eventually, the cost of those inconsistencies starts showing up in every new piece of work.

That's when I started treating the internal development setup as part of the product's foundations rather than just something I needed to get out of the way.

CI is not just about getting a green check

One of the recent areas I've been working on is how CI workloads are executed.

I've been moving selected trusted quality and deployment-validation jobs onto internal runners while keeping a separation for pull-request execution where appropriate.

The interesting part wasn't simply changing where a job runs.

It was thinking about what should run where, what the trust boundary is, and how to keep the workflow maintainable.

A self-hosted runner can give you more control over resources and execution, but it also gives you responsibility for the machine, its security, its availability, and its maintenance.

That's the trade-off.

You don't get operational control for free.

And this is exactly the kind of decision that is easy to underestimate when you're focused on shipping features.

Rules become important when you're no longer working in one repository

Another area I've been working on is consistency across the codebase.

When you have several repositories and AI-assisted development workflows, it's surprisingly easy for different parts of the system to drift toward different assumptions.

One repository follows one convention. Another has an older rule. A tool makes a change that is locally reasonable but doesn't fit the wider architecture.

So I've been working on shared governance and project rules, including a newer version of the agent governance model that is inherited across the main repositories.

That may sound like internal process work, and it is.

But the goal is practical: make it easier to understand which rules are authoritative, which decisions belong to which components, and how changes should be reviewed.

I don't want every new task to require rediscovering the architecture.

At the same time, I'm learning that governance can become its own form of complexity if you're not careful.

The goal isn't to create more documents.

It's to reduce ambiguity.

The danger of enjoying the infrastructure too much

This is probably the most uncomfortable lesson for me.

I genuinely enjoy building systems.

I like understanding how the pieces fit together. I like improving development workflows. I like making infrastructure more reliable.

And because I enjoy it, it's easy to spend more time there than I originally intended.

There is always another improvement available.

Another configuration to clean up.

Another workflow to standardize.

Another tool to integrate.

Another architectural decision to revisit.

Some of that work is necessary.

Some of it is probably just interesting engineering.

As a solo founder, I have to learn the difference.

Because a better internal system is not the same thing as a better business.

The product still has to reach users

Dulvarn is a release intelligence and decision platform.

The core problem I'm working on is how teams can turn fragmented engineering, QA, security, change, and operational signals into an explainable release decision.

That is the reason the product exists.

Not because I wanted to build a complicated infrastructure setup.

Not because I wanted to collect as many technologies as possible.

Not because I wanted to create a perfect internal engineering environment.

The infrastructure is there to support the product.

The product is there to solve a problem.

And the problem has to matter to real users.

That's the part I need to keep returning to.

What I'm trying to do differently

I'm becoming more deliberate about separating foundational work from product work.

When something is genuinely blocking development or creating unacceptable risk, it needs attention.

But once the blocker is removed, I need to resist the urge to keep polishing the foundation indefinitely.

The next question should be:

What is the smallest useful product step I can take now?

That might be improving onboarding.

It might be making the release decision easier to understand.

It might be simplifying a workflow.

It might be preparing a demo.

Or it might be talking to someone who has the problem Dulvarn is supposed to solve.

Those steps can be less satisfying than solving a difficult technical problem.

But they're necessary if the goal is to build a product rather than just a technically interesting system.

Building while working full-time makes prioritization unavoidable

I'm building Dulvarn alongside a full-time job.

That means I can't treat every task as equally important.

Time and energy are limited.

If I spend an evening improving infrastructure, that's an evening I didn't spend on onboarding, customer discovery, documentation, or marketing.

Sometimes that's the right decision.

Sometimes it isn't.

And I don't think there's a perfect formula for it.

I'm trying to get better at asking what a task actually unlocks.

Does it remove a blocker?

Does it reduce a meaningful risk?

Does it improve the experience of a potential user?

Does it help me learn whether the product solves a real problem?

Or am I doing it because it's interesting and I know how to do it?

That last question is often the hardest one.

One of the reasons I started this series was to share the real process of building a SaaS, not just the polished milestones.

That includes the weeks when the visible product doesn't change much.

The architecture decisions.

The infrastructure work.

The mistakes.

The features I decide not to build.

The moments when I realize I've spent too much time on something.

And the process of getting back to the actual product.

I think those parts are worth sharing because they're part of what building a SaaS really looks like.

Especially when you're doing it as a solo founder.

What comes next

My focus is to keep moving Dulvarn toward a product experience that is useful and understandable for real teams.

That means continuing the work around onboarding, release workflows, evidence, and the way users understand release decisions.

It also means getting back to conversations with potential users and learning which parts of the problem are painful enough that teams would actually want help solving them.

I don't want to pretend that every feature is finished or that every part of the roadmap is equally mature.

There is still work to do.

And I'd rather share that honestly than turn the journey into a series of perfect progress updates.

Building a SaaS is teaching me that progress isn't always visible.

Sometimes progress is a new feature.

Sometimes it's removing a blocker.

Sometimes it's making a difficult architectural decision.

And sometimes it's realizing that the next thing you need to build isn't more infrastructure.

It's a better way for someone to understand and use the product.

The challenge is knowing which kind of progress matters most right now.

This is the second article in my How I’m Building a SaaS series.

If you're building your own product, how do you decide when the foundations are good enough and it's time to get back to features, users, and validation?

Engineering a Non-Custodial Bitcoin Paywall for an AI Assistant

Mon, 31 Aug 2026 07:12:12 +0000

Engineering a Non-Custodial Bitcoin Paywall for an AI Assistant

We recently completed the first real Bitcoin payment for Zorgax, the AI assistant inside the MyZubster ecosystem.

The goal was not simply to display a wallet address. We wanted a complete production flow that could connect a verified on-chain payment to an authenticated account and automatically activate paid features.

The final lifecycle looks like this:

Authentication
      ↓
Payment intent
      ↓
External Bitcoin wallet
      ↓
Blockchain transaction
      ↓
Independent verification
      ↓
Entitlement activation
      ↓
Backend feature access

Zorgax access levels

Zorgax currently provides three plans:

Free
- Basic AI assistant
- Limited web research
- Maximum 2 sources

Pro — €9.90 monthly equivalent
- Advanced web research
- Maximum 5 sources
- Zorgax workspace

Developer — €29.90 monthly equivalent
- Everything in Pro
- Maximum 8 sources
- Direct API access
- Automation features

The current Bitcoin flow creates time-bounded access. It is not an automatic recurring wallet subscription.

Why a wallet address is not enough

A public Bitcoin address can receive payments, but it cannot answer several application-level questions:

Which account made the payment?
Which plan was selected?
What BTC amount was expected?
When was the exchange-rate quote generated?
Has this transaction already been used?
When should the entitlement expire?

For this reason, Zorgax creates a persistent payment intent before displaying the payment instructions.

{
  "intentId": "payment-intent-id",
  "ownerId": "authenticated-user",
  "plan": "pro",
  "asset": "BTC",
  "destination": "bitcoin-address",
  "expectedAmountSats": 14728,
  "status": "PENDING",
  "expiresAt": "quote-expiration"
}

The exact amount varies according to the quote generated for the order.

Creating the checkout

The authenticated frontend requests a new payment intent:

const response = await fetch(
  "/api/zorgax/assistant/checkout/intent",
  {
    method: "POST",
    headers: {
      "Content-Type": "application/json",
      Authorization: `Bearer ${token}`
    },
    body: JSON.stringify({
      plan: "pro",
      asset: "BTC"
    })
  }
);

The backend associates the intent with the current user and returns:

The BTC destination
The exact amount
The expiration time
The payment-intent identifier

The user then pays from an external wallet.

MyZubster never requests the private key and never signs or broadcasts the transaction.

Verifying the transaction

After broadcasting the payment, the user receives a Bitcoin transaction ID.

The TXID is submitted to the verification endpoint:

await fetch(
  `/api/zorgax/assistant/checkout/intent/${intentId}/verify`,
  {
    method: "POST",
    headers: {
      "Content-Type": "application/json",
      Authorization: `Bearer ${token}`
    },
    body: JSON.stringify({
      paymentReference: txid
    })
  }
);

The server then retrieves the public transaction and checks:

Transaction exists
        ↓
Correct destination
        ↓
Sufficient amount
        ↓
Required confirmations
        ↓
Intent belongs to the user
        ↓
Payment has not already been consumed

A simplified verifier looks like this:

const transaction = await getBitcoinTransaction(txid);

const output = transaction.outputs.find(
  item => item.address === intent.destination
);

if (!output) {
  throw new Error("Unexpected payment destination");
}

if (output.value < intent.expectedAmountSats) {
  throw new Error("Insufficient payment amount");
}

if (transaction.confirmations < minimumConfirmations) {
  throw new Error("Insufficient blockchain confirmations");
}

Why confirmations matter

During the first live production test, Zorgax detected the transaction while it was still in the mempool.

The application returned:

Payment not activated:
Insufficient blockchain confirmations

This was expected.

Seeing a transaction in the mempool does not mean the system should immediately grant paid access. Zorgax waited until the payment entered a Bitcoin block.

After the required confirmation, the same TXID was verified again:

Payment verified
Access ACTIVE
Plan Pro

No second payment was required.

Activating the entitlement

After successful verification, Zorgax creates or updates the account’s entitlement:

{
  "plan": "pro",
  "tier": "PRO",
  "status": "ACTIVE",
  "source": "BITCOIN_PAYMENT",
  "startsAt": "activation-date",
  "expiresAt": "expiration-date"
}

Every protected request evaluates this access state before running the requested operation.

Enforcing access on the backend

Hiding a button in the frontend is not security.

The backend applies an access policy to every Zorgax request:

const policies = {
  guest: {
    chat: true,
    webResearch: false,
    workspace: false,
    directApi: false
  },

  free: {
    chat: true,
    webResearch: true,
    maxWebResults: 2,
    workspace: false,
    directApi: false
  },

  pro: {
    chat: true,
    webResearch: true,
    maxWebResults: 5,
    workspace: true,
    directApi: false
  },

  developer: {
    chat: true,
    webResearch: true,
    maxWebResults: 8,
    workspace: true,
    directApi: true
  }
};

For example, direct research requires the Developer tier:

router.get(
  "/research",
  authenticate,
  requireZorgaxPlan("developer"),
  researchHandler
);

Workspace persistence requires Pro or higher:

router.post(
  "/data/commit",
  authenticate,
  requireZorgaxPlan("pro"),
  commitHandler
);

Guest access without silent authentication failures

Zorgax supports guest chat, but an invalid token must never silently become a guest session.

The authentication boundary is:

No token
→ Guest access

Valid token
→ Authenticated access

Invalid token
→ 401 Unauthorized

This distinction prevents expired or manipulated credentials from bypassing protected logic.

Unifying legacy subscriptions and new entitlements

MyZubster already had legacy subscription records. The new payment implementation introduced a more explicit entitlement model.

We created one access service that evaluates both:

Legacy subscriptions ─┐
                      ├── Unified Zorgax access
New entitlements ─────┘

The service selects the highest active plan and returns a single feature policy.

This allows existing accounts to remain compatible while new Bitcoin payments use the improved lifecycle.

A Vercel routing problem

The application also contains a generic Zorgax AI gateway route.

A broad rule such as:

/api/zorgax/*

could intercept requests intended for the monetization backend.

The specific monetization route now takes priority:

{
  "source": "/api/zorgax/monetization/(.*)",
  "destination": "/api/index.js"
}

Only afterward does the generic AI proxy apply.

This ensures that purchases and entitlements are handled by the backend containing the correct authentication middleware and database connection.

Confirming persistent AI writes

Zorgax can prepare structured data, but it does not silently persist AI-generated content.

The workspace flow requires:

A generated preview.
A cryptographic digest of that preview.
An explicit user confirmation.
Digest validation before persistence.

const expectedDigest = digestPreview(preview);

if (expectedDigest !== submittedDigest) {
  throw new Error("Preview changed");
}

This creates a clear boundary between AI suggestions and authorized writes.

Production verification

Before deployment, the Zorgax test family completed:

58 test suites
206 tests passed

Production checks confirmed that:

Public pricing                  → 200
Guest chat                      → 200
Guest web research              → disabled
Protected monetization routes   → 401 without login
Developer research API          → 401 without login
Checkout                        → 401 without login

The real Bitcoin transaction then proved the final missing part: verified payment-to-entitlement activation.

Security boundaries

The production design follows these rules:

No private keys are accepted.
MyZubster does not sign transactions.
Users pay from external wallets.
The destination and amount are verified.
Blockchain confirmations are required.
Payment intents belong to authenticated users.
Paid features are enforced server-side.
Persistent writes require explicit confirmation.
Invalid tokens never become anonymous sessions.

What comes next

The current system is operational but intentionally conservative.

Possible next improvements include:

Renewal notifications
Payment-history dashboards
Downloadable receipts
Additional independent Bitcoin providers
More supported settlement assets
Entitlement-expiration reminders
Better transaction monitoring

Every new asset will require its own trusted quote source, verification logic and confirmation policy.

Final result

Zorgax monetization is no longer only a pricing page.

A real production payment successfully completed this sequence:

BTC payment
→ blockchain confirmation
→ independent verification
→ entitlement activation
→ Pro features enabled

The result was:

Access: ACTIVE
Plan: Pro

Project links

Zorgax:

https://www.myzubster.com/zorgax

MyZubster source code:

https://github.com/MyZubster-Ecosystem/myzubster

Production monetization implementation:

https://github.com/MyZubster-Ecosystem/myzubster/commit/d7a579cd89801d29ac094a19af42fb17350691ef

We Completed the First Live Bitcoin-to-Pro Activation on MyZubster

Mon, 31 Aug 2026 07:04:21 +0000

We Completed the First Live Bitcoin-to-Pro Activation on MyZubster

Today we reached a major milestone: Zorgax successfully processed a real Bitcoin payment and activated Pro access in production.

This was a complete end-to-end test, not a simulated checkout.

The production flow was:

MyZubster login
      ↓
Zorgax payment intent
      ↓
External Bitcoin wallet
      ↓
On-chain transaction
      ↓
Blockchain confirmation
      ↓
Independent verification
      ↓
Pro access activated

What is Zorgax?

Zorgax is the AI assistant inside the MyZubster ecosystem.

It combines:

General AI assistance
Web research
Source collection
Structured-data preparation
Workspace features
Developer APIs
Bitcoin-based access activation

The available plans are:

Free       €0
Pro        €9.90
Developer  €29.90

Free users receive limited research, Pro users gain workspace features and additional sources, while Developer accounts can access automation and direct APIs.

A non-custodial payment architecture

MyZubster does not request, store or manage users’ private keys.

Users send Bitcoin through their own external wallet. Zorgax only creates a payment intent and records:

The selected plan
The expected BTC amount
The destination address
The expiration time
The submitted transaction ID
The verification status

The backend then verifies the public transaction independently.

A simplified version of the process looks like this:

const payment = await verifyTransaction(txid);

if (payment.destination !== intent.destination) {
  throw new Error("Unexpected payment destination");
}

if (payment.amount < intent.expectedAmount) {
  throw new Error("Insufficient payment amount");
}

if (payment.confirmations < minimumConfirmations) {
  throw new Error("Insufficient blockchain confirmations");
}

await activateEntitlement({
  ownerId: intent.ownerId,
  plan: intent.plan,
  status: "ACTIVE"
});

The application never signs or broadcasts a transaction.

Waiting for blockchain confirmation

During the live test, Zorgax detected the transaction but initially returned:

Payment not activated:
Insufficient blockchain confirmations

This was the expected behavior.

The system did not activate Pro access simply because a valid-looking TXID had been submitted. It waited until the transaction had the required blockchain confirmation.

After confirmation, we submitted the same TXID again:

Payment verified
Access ACTIVE
Plan Pro

Backend access enforcement

We also implemented server-side feature enforcement.

Guest
- Basic chat
- No live web research

Free
- Limited research
- Maximum 2 sources

Pro
- Advanced research
- Maximum 5 sources
- Zorgax workspace

Developer
- Higher limits
- Automation
- Direct research API

These restrictions are enforced by the backend, not only hidden in the user interface.

Protected endpoints return authentication or payment-required responses when the account does not have the necessary plan.

Fixing a production routing problem

During implementation, we discovered that the generic Zorgax gateway could intercept monetization requests.

The Vercel routing order was corrected so that:

/api/zorgax/monetization/*

is processed by the authenticated MyZubster backend before the generic AI proxy route.

This ensures that purchases, subscriptions and entitlements use the correct database and authentication middleware.

Unifying subscriptions and entitlements

The project contained both legacy subscription records and newer entitlement records.

We introduced a unified access service that:

Checks both stores.
Selects active records.
Chooses the highest available plan.
Fails safely when access cannot be verified.
Returns a single policy to every Zorgax endpoint.

This keeps older subscriptions compatible with the new payment system.

What the live test proves

The successful transaction proves that the following components work together in production:

Authentication
Payment-intent generation
BTC amount calculation
External wallet payment
TXID submission
Destination validation
Amount validation
Confirmation validation
Database persistence
Pro entitlement activation
Feature-access enforcement

It transforms Zorgax monetization from a pricing interface into a functioning production system.

Current boundaries

The first release intentionally remains conservative:

Bitcoin is currently the operational settlement asset.
Payments are non-custodial.
Private keys are never accepted.
Access activation requires independent verification.
Automatic recurring billing is not currently enabled.

Future work can add renewal notifications, payment dashboards, downloadable receipts and more independent blockchain providers.

Explore the project

Zorgax:

https://www.myzubster.com/zorgax

MyZubster repository:

https://github.com/MyZubster-Ecosystem/myzubster

Production monetization update:

https://github.com/MyZubster-Ecosystem/myzubster/commit/d7a579cd89801d29ac094a19af42fb17350691ef

The next goal is to make the complete payment and entitlement lifecycle easier to monitor while preserving the non-custodial design.

How a QA Problem Turned Into the SaaS I’m Building

Sat, 29 Aug 2026 14:19:38 +0000

I didn’t start building Dulvarn because I wanted to become a SaaS founder.

At least, not at first.

I started with a problem I kept seeing again and again in software delivery.

A team could have:

green CI
passing tests
successful builds
approved pull requests
deployment steps ready

And still, one question remained difficult to answer clearly:

Are we actually ready to release?

That question stayed with me.

Because in theory, software teams already have many signals.

CI tells us something.

Automated tests tell us something.

QA tells us something.

Security tools tell us something.

Pull requests tell us something.

Monitoring tells us something.

But those signals are often scattered across different tools, dashboards, tickets, reports, and conversations.

And when it is time to make the final release decision, the answer is not always as clear as the pipeline color suggests.

That gap is where Dulvarn started.

Green does not always mean confident

One of the ideas I kept coming back to was simple:

A green pipeline tells you that the checks you defined passed.

That is valuable.

But it does not automatically tell you that the release risk is low.

For example:

Build                     PASS
Automated tests           PASS
Security scan             PASS

Database migration        YES
Authentication change     YES
Rollback confidence       MEDIUM
Observability coverage    PARTIAL
QA coverage               LIMITED

Nothing here is necessarily red.

But it also does not feel like a release decision that should be made blindly.

The build passed.

The tests passed.

The scan passed.

But the release still deserves thought.

What changed?

How risky is the change?

Can we roll it back?

Do we have enough visibility after deployment?

Do we understand the weakest part of the release?

That difference between technical validation and release confidence became more interesting to me over time.

And once I noticed it, I started seeing it everywhere.

QA taught me to ask uncomfortable questions

Working in QA changes the way you look at software.

You naturally start asking:

What could fail?
What was not covered?
What assumption are we making?
What happens if the user does something unexpected?
What changed between environments?
What evidence do we actually have?

At first, those questions were mostly about features.

Does login work?

Can the user complete checkout?

Does validation behave correctly?

Does the API return the expected response?

But as I moved deeper into automation, CI/CD, DevOps, observability, and release engineering, the questions became broader.

I started asking:

What happens if the deployment succeeds, but the system becomes unhealthy?

What if the tests pass, but rollback is unclear?

What if the release includes a risky migration?

What if different teams each have part of the evidence, but nobody has the whole picture?

At that point, the problem was no longer only testing.

It was release decision-making.

Release readiness is often spread across too many places

In many teams, release evidence is not missing.

It is fragmented.

One signal lives in CI.

Another lives in test reports.

Security findings live somewhere else.

Deployment status is in another system.

Approvals may be in a ticket.

Important context may be in Slack.

Risk may be understood by one engineer, but not written down anywhere.

And then someone has to decide whether the release should go out.

That decision can become strangely informal compared to everything that came before it.

Code review is structured.

CI is structured.

Testing is structured.

Deployment is often structured.

But the release decision itself can still depend on scattered context and human memory.

That bothered me.

Not because people were careless.

But because the tools around them were usually optimized for execution.

Build.

Test.

Deploy.

They were less focused on the decision between those steps.

Dulvarn started as a release control idea

The idea behind Dulvarn came from that gap.

I wanted to explore a simple question:

What if release decisions were based on collected evidence instead of scattered signals and assumptions?

Not to replace CI.

Not to replace QA.

Not to replace DevOps.

And definitely not to replace people.

The point is not to make software delivery fully automatic and hope for the best.

The point is to make release risk more visible.

Something like:

CI
QA
Security
Change Context
Deployment Readiness
Operational Signals
Approvals
        ↓
Release Evidence
        ↓
Risk Context
        ↓
GO / CONDITIONAL GO / NO-GO

The label matters less than the explanation behind it.

A good release decision should not only say:

GO

It should also explain why.

And if the answer is:

CONDITIONAL GO

Then the team should understand the condition.

And if the answer is:

NO-GO

Then the reason should be clear enough to act on.

That is the direction I started building toward.

I am not trying to build another giant platform

One thing I care about is keeping the core idea clear.

Software teams already have enough tools.

They do not need another huge platform that tries to replace everything they use.

The interesting part is the layer between existing systems.

Collect the signals.

Understand the context.

Evaluate the risk.

Make the decision visible.

Keep the evidence.

That is the part I keep coming back to.

Dulvarn is not meant to be a magical AI system that takes control away from teams.

It is meant to support human-controlled release decisions.

The software can help organize evidence.

It can highlight risk.

It can make patterns easier to see.

It can preserve decision history.

But the responsibility still belongs with people.

That matters to me.

Especially because release decisions are not only technical.

They involve judgment.

Building the idea was easier than defining the product

This was one of the first lessons I learned.

Writing code is only one part of building a SaaS.

You also need to answer questions like:

Who exactly is this for?
Which problem is painful enough to solve?
What belongs in the MVP?
What should not be built yet?
How should onboarding work?
What should users see first?
What should remain manual?
What should be automated?
What is useful now, and what is just interesting?

Those questions are often harder than building another endpoint or UI component.

And they do not have clean pass/fail answers.

As a QA engineer, I was used to looking for defects.

As a product builder, I had to start looking for unnecessary complexity too.

That is a different skill.

And I am still learning it.

The temptation to build too much is real

When you build your own product, every idea feels useful.

Add another integration.

Add another dashboard.

Add another AI feature.

Add another report.

Add another workflow.

Add more settings.

Add more intelligence.

The product can become impressive very quickly.

It can also become impossible to understand.

I had to learn that a technically strong feature is not automatically a product priority.

Sometimes the better decision is:

Not yet.

That is surprisingly difficult when you are the person imagining the system and building it at the same time.

Because you can see the future version in your head.

But users do not start with the future version.

They start with the first useful version.

And that version has to be clear.

Building while working full-time changes everything

There is another reality behind Dulvarn.

I am building it while working a full-time job.

That means time matters.

Energy matters.

Focus matters.

You cannot treat every idea like an emergency.

You cannot spend weeks polishing something nobody has asked for.

You cannot rebuild the architecture every time a more elegant solution appears.

At least, not if you want to ship something.

This has forced me to think much more seriously about priorities.

What moves the product forward?

What creates evidence that the idea is useful?

What helps me get closer to real users?

What is just interesting engineering?

Those are different things.

And as a technical founder, it is very easy to confuse them.

Building Dulvarn changed the way I think about QA

Interestingly, building a SaaS has also made me think differently about QA.

When you own the whole product, quality becomes much bigger than testing.

A confusing onboarding step matters.

A broken deployment matters.

A slow page matters.

A missing error message matters.

Security matters.

Observability matters.

Documentation matters.

Support experience matters.

Pricing clarity matters.

The product is not only the code.

The product is the whole experience around the code.

That perspective feeds back into how I think about software quality in general.

Quality does not start when testing begins.

And it does not end when QA says passed.

It exists across the full lifecycle of the product.

This is still early

Dulvarn is not a finished story.

It is still early.

There are things I will probably change.

Features I will remove.

Assumptions I will test.

Positioning I will sharpen.

Workflows I will simplify.

Technical decisions I will rethink.

That is part of the process.

I do not want to write this series as if I already have everything figured out.

I do not.

I am building, learning, cutting scope, testing ideas, and trying to turn a real QA and release engineering problem into something useful.

That is exactly why I want to document it.

Not as a perfect founder story.

More as a record of what I am learning while building.

In this series, I want to write about the real process behind building Dulvarn.

Things like:

how I decide what belongs in the MVP
how I think about release risk
what I learn from user feedback
how I approach onboarding
how I avoid building too much
how I think about pricing
how I balance AI with human control
how I work on infrastructure
how I manage product decisions while working full-time
what I build and later remove

Not as a tutorial for building the perfect SaaS.

I definitely do not have that.

More as a practical founder log from someone trying to build a product from a problem he understands deeply.

Dulvarn did not start because I wanted to become a SaaS founder.

It started because QA kept leading me toward bigger questions.

Testing led to automation.

Automation led to CI/CD.

CI/CD led to DevOps.

DevOps led to release engineering.

And release engineering led to one question I could not stop thinking about:

If all our systems produce signals, who actually turns those signals into a release decision?

I am still working on the answer.

And I am building a product around it.

This is the first article in my How I’m Building a SaaS series.

In the next article, I want to write about one of the hardest lessons so far:

how to decide what not to build.

How to Build a SaaS with Next.js and MongoDB in 2026 (Complete Guide)

Fri, 28 Aug 2026 09:41:09 +0000

Building a SaaS product from scratch involves the same handful of pieces every time. Authentication, a database that actually scales, subscription billing, and a dashboard people can use without a manual. None of these are individually hard. Getting all of them working together, correctly, is where most side projects stall out.

This is the full path, from an empty folder to something you could actually charge people for, using Next.js 15 and MongoDB.

Step 1: Set Up the Foundation

Start with the App Router, TypeScript, and a folder structure that will not need restructuring once the project grows. Route groups separate your public marketing pages, authenticated dashboard, and API routes cleanly, without affecting the actual URLs.

src/
├── app/
│   ├── (marketing)/     ← public landing pages
│   ├── (auth)/          ← login, signup
│   ├── (dashboard)/     ← authenticated app
│   └── api/webhooks/    ← Stripe, etc.
├── lib/
├── models/
└── actions/

Getting this right early avoids the painful restructuring that happens when a flat app/ folder grows past a dozen pages with no separation between public and authenticated routes.

Step 2: Connect MongoDB the Right Way

A cached connection pattern is non-negotiable for anything deployed on Vercel or another serverless platform. Without it, hot reloads in development and cold starts in production both create new connections faster than MongoDB wants to accept them.

// lib/db.ts
import mongoose from 'mongoose';

let cached = (global as any).mongoose || { conn: null, promise: null };

export async function connectDB() {
  if (cached.conn) return cached.conn;
  if (!cached.promise) {
    cached.promise = mongoose.connect(process.env.MONGODB_URI as string);
  }
  cached.conn = await cached.promise;
  return cached.conn;
}

From here, every model, User, Subscription, and whatever your product's core data actually is, follows the same pattern, checking mongoose.models.X before defining a new one so hot reload does not throw an overwrite error.

Step 3: Authentication

JWT stored in an httpOnly cookie keeps the token out of reach of client-side JavaScript, which closes off the most common token-theft path through XSS. Middleware checks the cookie before a protected route even starts rendering, and a second check inside the dashboard layout catches anything middleware might miss.

// middleware.ts
export function middleware(request: NextRequest) {
  const session = request.cookies.get('auth-token');
  if (!session && request.nextUrl.pathname.startsWith('/dashboard')) {
    return NextResponse.redirect(new URL('/login', request.url));
  }
}

Role-based access, separating "not logged in" from "logged in but not allowed here", sits on top of this once you have more than one type of user, admin versus regular user, for example.

Step 4: Subscription Billing with Stripe

This is the step people try to shortcut, and it always causes problems later. Do not update subscription status based on the success redirect after checkout. Browsers close, redirects fail to load, and your database never finds out what actually happened.

Webhooks are the only reliable source of truth:

// app/api/webhooks/stripe/route.ts
case 'checkout.session.completed': {
  const session = event.data.object as Stripe.Checkout.Session;
  await User.findByIdAndUpdate(session.metadata?.userId, {
    subscriptionStatus: 'active',
  });
  break;
}

The rest of your app reads subscriptionStatus straight from the database, never calling Stripe directly just to check if a user has access. The webhook is what keeps that field accurate.

Step 5: The Dashboard Itself

Server Components handle almost all of the actual data fetching, no client-side loading spinners for data that is available the moment the page renders. Search, filters, and pagination live in the URL rather than component state, which keeps a filtered view shareable and refresh-safe.

// app/(dashboard)/customers/page.tsx
export default async function CustomersPage({ searchParams }) {
  const { search, page } = await searchParams;
  const { customers, totalPages } = await getCustomers({ search, page });

  return (
    <div>
      <CustomerFilters />
      <CustomerList customers={customers} />
      <Pagination currentPage={Number(page) || 1} totalPages={totalPages} />
    </div>
  );
}

Client Components only wrap the pieces that are actually interactive, a filter input, a modal, a button with local state, keeping the JavaScript shipped to the browser as small as it can reasonably be.

Step 6: Forms, Validation, and Error Handling

One Zod schema per form, shared between client-side validation (instant feedback as someone types) and the Server Action itself (the real check, since client validation can always be bypassed). Route-level error.tsx files catch anything unexpected without taking down the rest of the app, and notFound() handles missing records cleanly as an actual 404 rather than a crash.

Step 7: Email and Notifications

Verification emails, password resets, and payment receipts are expected in any real SaaS. Triggering the receipt email from inside the Stripe webhook, not from the client-side redirect, keeps it reliable for the same reason the subscription status update needs to happen there. Writing templates as actual React components, rather than raw HTML strings, makes this part of the stack far less painful to maintain.

Step 8: Real-Time Features, If You Need Them

Not every SaaS needs this, but anything with a live status, a queue, a dashboard that multiple people watch at once, benefits from pushing updates instead of polling. Trigger events from the server after a database write, and treat the database as the source of truth, with real-time events as a fast notification layer on top rather than a replacement for it.

Step 9: Rate Limiting and Security

Public endpoints, a contact form, a signup route, need rate limiting before they see real traffic, not after something abuses them. A sliding window limiter keyed by IP for unauthenticated routes, or by user ID for authenticated ones, catches both accidental retry loops and deliberate abuse. Every route still needs its own input validation on top of this, since rate limiting controls how often, not what gets sent.

Step 10: SEO for the Marketing Pages

The dashboard itself does not need to rank in search results, but the marketing pages around it do. Unique metadata per page through generateMetadata, a generated sitemap that updates automatically as content is added, and canonical URLs to avoid a www versus non-www split are the baseline. From there, actual content, a blog, comparison pages, documentation, is what builds the organic traffic a SaaS needs to reduce dependence on paid acquisition.

What This Actually Takes to Build From Scratch

Realistically, a solo developer building all of this correctly, connection caching, auth, billing, a working dashboard, emails, basic security, is looking at real weeks of work before the first paying customer could even sign up, longer if any of these pieces are unfamiliar.

This is exactly the gap a well-built template closes. Not because the concepts are hard to learn, everything above is a pattern, not a secret, but because assembling all of them correctly, with the pieces actually wired together instead of built in isolation, is where the time actually goes.

Frequently Asked Questions

Is MongoDB a good choice for a SaaS product, or should I use a SQL database?
MongoDB works well for SaaS products with flexible or evolving data shapes, since schema changes do not require a migration in the same way a relational database does. For data with strict relational integrity requirements, financial ledgers, complex multi-table joins, a SQL database like Postgres is often a better fit. Many SaaS products end up using both, MongoDB for flexible application data, a relational database for anything requiring strict consistency.

How long does it take to build a SaaS MVP with Next.js?
For an experienced developer working solo, a focused MVP covering auth, one core feature, and basic billing typically takes several weeks of consistent work. Scope is the biggest variable, an MVP that tries to include every feature from the start almost always takes longer than one built around a single, well-defined core workflow.

Do I need a separate backend, or can Next.js handle the whole SaaS?
For most SaaS products, Next.js alone is sufficient. Server Actions and API routes handle backend logic, and Server Components handle data fetching, without needing a separate Express or Node server running alongside it. A separate backend becomes worth considering only for very specific needs, like a long-running background process that does not fit a serverless request-response model.

If you want to see this exact architecture already built, rather than assembling it piece by piece, I sell Next.js and MongoDB SaaS templates with auth, billing, and a working dashboard already wired together.

Browse templates: https://pixelanas.gumroad.com

Building something specific and want a hand with it? Get in touch: https://pixelanas.com/contact

Anas, full-stack Next.js developer building SaaS products and premium templates. X: @ASheikh69751

From Making Features Work to Designing Systems: Anik Sikder on Architecture, SaaS, and Scale

Wed, 26 Aug 2026 00:47:30 +0000

From Making Features Work to Designing Systems: Anik Sikder on Architecture, SaaS, and Scale

From full-stack development to system design, multi-tenant SaaS, distributed systems, and AI-powered business automation.

Meet Anik Sikder

When you're starting out as a developer, success can feel very simple:

Does the feature work?

Authentication works.
The inventory page works.
The API returns the right response.

Ship it.

But as systems grow, the definition of "working" changes.

A feature that works for 10 users may struggle with 10,000. A design decision that seems harmless today can become a serious bottleneck later. And a system that is easy to build can become surprisingly difficult to maintain.

Anik Sikder has experienced that evolution firsthand.

Anik is a Full-Stack Engineer focused on SaaS, ERP and business systems, working primarily with technologies including Python, Django, FastAPI, React and Next.js. His current work focuses on multi-tenant SaaS architecture, ERP and business operating systems, RBAC, API design, system design and distributed systems. :contentReference[oaicite:3]{index=3}

He's also building BizNex OS, a multi-tenant ERP platform designed to bring areas such as inventory, procurement, sales, accounting, reporting, branches and warehouses into a connected business operating system. :contentReference[oaicite:4]{index=4}

But perhaps the most interesting part of Anik's journey is the change in how he thinks about software.

He started by asking:

"Does it work?"

Now he asks:

"How will it scale? What happens when something fails? Can another developer understand this six months from now? And what are the trade-offs?"

In this Developer Story, Anik shares how his thinking evolved from building individual features to designing entire systems, what building SaaS for real businesses taught him, why he chose a modular monolith for BizNex OS, what developers often misunderstand about distributed systems, and why architecture is ultimately about making good trade-offs.

Anik's Story

1. From Full-Stack Development to System Design

When I started, I was mostly focused on making features work.

If a user needed authentication, I built authentication.

If they needed inventory management, I built inventory management.

My success metric was simple:

Does it work?

Over time, I noticed that building features is actually the easiest part.

The hard part starts when the system grows.

A feature that works for 10 users might completely break down for 10,000 users. A design decision that feels harmless today can become a major bottleneck a year later.

That realization changed how I think.

Now, before writing code, I spend more time asking questions:

How will this scale?
What happens if this service goes down?
Can another developer understand this six months later?
What are the trade-offs?

I still enjoy coding, but architecture is where I find the most interesting problems.

Code solves today's problem. Architecture determines how many future problems you'll create.

2. Building SaaS for Real Businesses

One of the biggest lessons I've learned is that businesses don't buy software because it's technically impressive.

Developers love talking about frameworks, patterns, microservices, and scalability.

Business owners care about something much simpler:

"Will this save me time, money, or headaches?"

Early in my career, I focused heavily on technical elegance.

Later I realized that a simple solution that saves a business two hours a day is often more valuable than an architecturally beautiful system nobody uses.

Another thing I learned is that business processes are usually messy.

When you're building software for real companies, you quickly discover that every company has exceptions, special cases, and weird workflows that nobody documented.

The challenge isn't simply building software.

The challenge is understanding how people actually work.

3. Building BizNex OS

The idea behind BizNex OS came from a problem I kept seeing repeatedly.

Many small and medium businesses use five or six different tools to run their operations.

One tool for sales.

Another for inventory.

Another for accounting.

Another for HR.

And spreadsheets everywhere.

The result is fragmented data.

Nobody has a complete picture of what's happening inside the business.

I wanted to build something that treats a business as a connected system rather than a collection of disconnected modules.

Honestly, from a startup perspective, building a smaller SaaS product would probably be easier.

But I wasn't interested in solving just one workflow.

I wanted to understand how an entire organization operates and design a system around that.

It's definitely harder.

But it's also much more interesting.

4. The Challenge of Multi-Tenancy

Multi-tenancy sounds simple until you start implementing it.

The biggest concern is always tenant isolation.

A bug that exposes one company's data to another company isn't just a bug.

It's a trust-destroying event.

Because of that, I made tenant boundaries a first-class architectural concern.

Most queries are organization-scoped by default.

Permissions are organization-scoped.

Roles are organization-scoped.

Instead of relying on developers to "remember" tenant filtering, I try to make the architecture enforce it whenever possible.

Another lesson is that maintainability matters more than cleverness.

There are many technically sophisticated multi-tenant strategies, but if the team can't understand them, they'll become future problems.

Sometimes boring architecture is the best architecture.

5. Architecture Is About Trade-offs

One example is the decision between a traditional monolith and a microservices architecture.

Microservices are attractive.

They look modern.

They solve certain scaling challenges.

They allow independent deployments.

But they also introduce complexity.

Service discovery, distributed tracing, network failures, eventual consistency, and operational overhead — none of these exist in the same way in a simple monolith.

For BizNex OS, I chose a modular monolith approach.

Not because microservices are bad.

Because the complexity cost wasn't justified yet.

A lot of architecture decisions become easier when you stop asking:

"What's the most advanced solution?"

and start asking:

"What's the simplest solution that solves today's problem while keeping tomorrow's options open?"

That's how I think about architecture.

It's not about choosing the most impressive technology.

It's about choosing the right trade-off for the situation.

6. Learning from Large-Scale Systems

I don't study Facebook, Netflix, or Slack because I expect my projects to have billions of users.

I study them because they teach fundamental engineering principles.

For example:

Netflix teaches resilience.
Facebook teaches scalability.
Slack teaches real-time communication.

What I find most interesting is that large-scale companies rarely solve problems with magic.

Most of the time they're solving the same problems we face, just at a larger scale.

Understanding their trade-offs helps me think more clearly about my own designs.

Not every solution should be copied.

But every solution teaches something.

7. Distributed Systems and Event-Driven Architecture

What attracts me to distributed systems is that they force you to think differently.

In a monolith, a function call either succeeds or fails.

In distributed systems, everything becomes uncertain.

Networks fail.

Messages arrive late.

Services go down.

Data becomes temporarily inconsistent.

You start realizing that software is really about handling failure.

One thing developers often misunderstand is that distributed systems are not an upgrade.

They're a trade-off.

Many teams move toward microservices because it feels modern.

But distributed systems introduce problems that monoliths simply don't have.

If your application doesn't need that complexity, adding it early can slow you down rather than help you.

The goal shouldn't be to build the most distributed system possible.

The goal should be to build the system that makes sense for the problem.

8. From Project to Production

Building my event management and ticketing system taught me a lesson I'll probably never forget:

Making something work is easy. Keeping it working is hard.

When you're building a personal project, success means the feature works on your machine.

In production, success means:

It keeps working.
It handles unexpected input.
It survives failures.
It remains maintainable.

Authentication, payments, permissions, QR verification — none of these are difficult because of the happy path.

They're difficult because of all the edge cases.

Production engineering is really the art of handling edge cases before your users discover them.

That was one of the biggest differences I learned between simply building a project and engineering something that needs to survive in the real world.

9. AI and Business Automation

I think AI is most valuable when it removes repetitive work.

For example:

Document processing
Data extraction
Business insights
Workflow automation
Customer support assistance

These areas can generate immediate value.

Where I think the industry sometimes overuses AI is when AI is added simply because it's trendy.

Not every button needs a chatbot.

Not every workflow needs an LLM.

Sometimes a well-designed form solves the problem better than an AI assistant.

The question shouldn't be:

"Can we add AI?"

The question should be:

"Does AI actually improve the user's outcome?"

If the answer is no, don't add it.

10. Advice for Developers

The biggest shift is to stop thinking only about frameworks.

Frameworks change.

Principles don't.

Spend more time learning:

Databases
Networking
Distributed systems
Scalability
Reliability
Security
Business domains

Another thing I'd recommend is building systems, not tutorials.

Tutorials teach features.

Systems teach trade-offs.

And finally, study real-world architectures.

Whenever you use a product like Uber, Netflix, Amazon, Stripe, or Slack, ask yourself:

"How would I build this?"

That simple question has taught me more about system design than many courses.

You don't need to reproduce the exact architecture of a massive technology company.

The point is to start thinking about:

scale
failure
data
consistency
communication
security
reliability
and trade-offs

The goal isn't to become the smartest engineer in the room.

The goal is to make good engineering decisions consistently.

In my experience, that's what separates developers from architects.

From Features to Systems

Looking back at my own development journey, the biggest change wasn't learning another framework.

It was changing the questions I ask before writing the code.

Early on, I asked:

Does this feature work?

Now I ask:

What happens when the system grows?

What happens when something fails?

Can someone else maintain this?

What are the trade-offs?

Does this actually solve the business problem?

That shift is what moved my thinking from simply building features toward designing systems.

And I think that's one of the most important transitions a developer can make.

You don't necessarily become a better engineer by knowing more frameworks.

Sometimes you become a better engineer by learning to ask better questions.

About Anik Sikder

Anik Sikder is a Full-Stack Engineer focused on SaaS, ERP and business systems.

He works primarily with Python, Django, FastAPI, React and Next.js, with a particular interest in system design, multi-tenant SaaS architecture, distributed systems, RBAC, API design and business automation. :contentReference[oaicite:5]{index=5}

He is currently building BizNex OS, a multi-tenant ERP platform designed to bring business operations such as inventory, procurement, sales, accounting, reporting, branches and warehouses into a connected system. :contentReference[oaicite:6]{index=6}

Anik is also exploring distributed systems, event-driven architecture, AI-powered business automation and cloud infrastructure. :contentReference[oaicite:7]{index=7}

You can learn more about his work at aniksikder.me.

A Final Thought

Modern software development can sometimes feel like a race to learn the newest framework, architecture pattern, or AI tool.

But the deeper lesson from Anik's journey is simpler.

Good engineering isn't about choosing the most advanced technology.

It's about understanding the problem, understanding the constraints, and making the right trade-offs.

A monolith can be the right architecture.

A simple form can be better than an AI assistant.

A boring solution can be better than a clever one.

And sometimes the most valuable engineering skill isn't writing more code.

It's knowing what code should be written in the first place.

This Developer Story is part of CoderLegion's Developer Stories series, where we share the real journeys, experiences, challenges, and lessons of developers from our community.

Feature Flags in SaaS: A Beginner's Guide with Next.js 16 (2026)

Sun, 23 Aug 2026 05:03:07 +0000

You just shipped a new billing page. It works perfectly in your local environment, QA gives it a thumbs up, and you deploy on a Friday afternoon (bold choice). Twenty minutes later, support tickets start rolling in — the new checkout flow is broken for a chunk of your users, and the only fix is a full redeploy, which means more downtime while you scramble.

Here's the thing: that entire scenario is avoidable. Not by testing harder, but by changing how you ship. If that billing page had been behind a feature flag, you could've turned it off instantly — no redeploy, no rollback, no 2am panic. Just a toggle switch.

By the end of this guide, you'll understand exactly what feature flags are, why almost every real SaaS product uses them, and you'll have a working feature flag system built into a Next.js 16 app — from a simple database-backed version you can build yourself, to Vercel's official Flags SDK for a more polished setup.

Why This Is Tricky

Feature flags sound simple — "just an if statement," right? And technically, that's true. But most beginners either overuse them (turning every branch of code into a flag, creating a tangled mess) or underuse them (skipping flags entirely and relying only on git push to control what users see).

The real skill isn't writing an if statement — it's answering three questions correctly:

Where should the flag be checked? Client, server, or both?
Where should the flag's value live? Hardcoded, a database, or a third-party service?
What happens when the flag is wrong or missing? Does your app break, or fail safely?

We'll answer all three as we build this out.

What Is a Feature Flag, Exactly?

A feature flag (also called a feature toggle) is a switch in your code that controls whether a piece of functionality is active — without needing to change or redeploy your code to flip it.

💡 Think of it like: a light switch wired into your wall during construction, instead of soldering a lamp directly to the power line. The wiring (your code) ships once. Whether the light is on or off is a decision you can change any time, without touching the wall again.

In practice, a feature flag is just a boolean (or sometimes a string/number) that your code checks before rendering something or running some logic:

if (isNewCheckoutEnabled) {
  return <NewCheckout />;
}

return <OldCheckout />;

The interesting part isn't that if statement — it's where isNewCheckoutEnabled comes from and how you control it. That's what the rest of this guide covers.

Why SaaS Products Rely on Feature Flags

A handful of concrete reasons feature flags matter, especially for SaaS:

Ship without releasing. You can merge and deploy unfinished code to production behind a flag that's off. This is called "trunk-based development" — your main branch always reflects what's deployed, but not everything deployed is visible yet.
Instant kill switch. If something breaks, flip the flag off. No git revert, no redeploy, no waiting for a build to finish while your app is broken.
Gradual rollouts. Release a risky feature to 5% of users first, watch for errors, then dial it up to 25%, 50%, 100% — instead of an all-or-nothing launch.
Paid plan gating. Show a feature only to customers on your Pro or Enterprise plan, without maintaining separate codebases per plan.
A/B testing. Show two variants of a feature to different user segments and measure which one performs better.
Beta programs. Let specific users (or your own team) try a feature early, without exposing it to everyone.

💡 Tip: These use cases usually map to four flag types: release flags (hide unfinished work), ops flags (kill switches), permission flags (plan-based access), and experiment flags (A/B tests). Naming your flags after their type helps keep a growing flag list organized — more on this in the best-practices section.

Prerequisites

This guide uses:

Next.js 16 with the App Router
TypeScript in strict mode
Supabase as the database (the same pattern works with any Postgres/SQL database — just swap the client)
Tailwind CSS for the tiny UI examples

We'll build two versions of the same thing:

A do-it-yourself, database-backed flag system — no extra service, full control, great for learning how flags actually work under the hood.
The Vercel Flags SDK — an official, open-source toolkit purpose-built for Next.js that adds typed flags, a local override toolbar, and a clean pattern for swapping providers later.

You don't need both — pick whichever fits your project, or read both to understand the tradeoffs.

  User Request
      │
      ▼
Server Component
      │
      ▼
getFeatureFlag()
      │
      ▼
Next.js Cache
      │
      ├── Cache Hit ─────► true / false
      │
      ▼
  Supabase
      │
      ▼
 true / false
      │
      ▼
  Render UI

Part 1: Building Your Own Feature Flag System

This is the version to reach for if you want zero extra dependencies and full control over where flag data lives — a great fit if you're already using Supabase for your app's database.

Step 1: Create the Feature Flags Table

Every flag needs a key (a unique name), whether it's enabled, and optionally a rollout percentage for gradual releases.

-- Run this in the Supabase SQL editor
create table public.feature_flags (
  key text primary key,
  enabled boolean not null default false,
  rollout_percentage int not null default 100
  check (rollout_percentage between 0 and 100),
  description text,
  updated_at timestamptz not null default now()
);

-- Keep RLS on with no policies — only a service-role client can read this,
-- not even your normal server-side (cookie-based) Supabase client, and never the anon key.
alter table public.feature_flags enable row level security;

What's happening here: key is a plain text primary key like "new-checkout" — your code will reference flags by this string. enabled is the master on/off switch. rollout_percentage lets you release to a slice of users instead of everyone at once (100 means "everyone who has the flag enabled sees it," 25 means "only about a quarter of them do"). Enabling Row Level Security with no policies means this table isn't readable through the public API at all — only your server-side Supabase client (which uses full database access) can read it, which is exactly what you want for something that controls app behavior.

⚠️ Common Mistake: Leaving this table world-readable through the anon key. Even though flag values aren't usually "secret" in the sensitive-data sense, exposing your entire flag list (including unreleased feature names) to anyone poking at your API is an easy, avoidable leak.

Add a couple of test rows:

insert into public.feature_flags (key, enabled, rollout_percentage, description)
values
  ('new-checkout', true, 100, 'Redesigned checkout flow'),
  ('ai-summary', true, 20, 'AI-generated summary panel (early rollout)');

Step 2: Write a Deterministic Rollout Function

If rollout_percentage is 20, you want the same 20% of users to see the feature every time they visit — not a random 20% on every page load. That requires a deterministic check: given the same user and the same flag, always return the same answer.

// lib/flags/rollout.ts
import { createHash } from "crypto";

/**
 * Deterministically decides whether a given user falls inside a flag's
 * rollout percentage. The same userId + flagKey combination always
 * produces the same result, so a user doesn't flicker between the old
 * and new experience on every request.
 */
export function isInRollout(
  userId: string,
  flagKey: string,
  percentage: number
): boolean {
  if (percentage >= 100) return true;
  if (percentage <= 0) return false;

  const hash = createHash("sha256")
    .update(`${flagKey}:${userId}`)
    .digest("hex");

  // Take the first 8 hex characters, turn them into a number,
  // and reduce it to a bucket between 0 and 99.
  const bucket = parseInt(hash.slice(0, 8), 16) % 100;

  return bucket < percentage;
}

What's happening here: createHash("sha256") hashes the combination of the flag key and the user's ID. Because hashing is deterministic (the same input always produces the same output), the same user always lands in the same "bucket" (a number from 0–99) for a given flag. If that bucket number is less than the rollout percentage, they see the feature. Since we mix in the flag key too, the same user can be in the "in" bucket for one flag and the "out" bucket for a completely different flag — buckets aren't shared across flags.

Step 3: Create a Server-Only Function to Read a Flag

First create a service-role Supabase client

The feature_flags table has RLS enabled with no policies, so it can't be read by any client except one authenticated with your service role key — not even your normal server-side (cookie-based) Supabase client can see it. That's actually a good fit here, since flags are app-level configuration, not user data, and it also happens to be the client we need for caching: it has no cookies or per-request session attached, which Next.js requires for anything wrapped in "use cache".

// lib/supabase/service-client.ts
import { createClient } from "@supabase/supabase-js";

// Service-role client — bypasses RLS, no cookies/session attached.
// Only ever use this for trusted, server-only reads like feature flags.
// Never import it into a Client Component, and never prefix the key with NEXT_PUBLIC_.
export const supabaseAdmin = createClient(
  process.env.NEXT_PUBLIC_SUPABASE_URL!,
  process.env.SUPABASE_SERVICE_ROLE_KEY!
);

⚠️ Common Mistake: Leaking the service role key to the browser. It must stay a plain (non-NEXT_PUBLIC_) environment variable, set only in your server environment — this key bypasses every RLS policy in your database, so treat it with the same care as a database password.

// lib/flags/get-flag.ts
import { supabaseAdmin } from "@/lib/supabase/service-client";
import { isInRollout } from "./rollout";

/**
 * Reads a feature flag's value for a given user.
 * Server-only — never call this from a Client Component.
 */
export async function getFeatureFlag(
  key: string,
  userId?: string
): Promise<boolean> {
  const { data, error } = await supabaseAdmin
    .from("feature_flags")
    .select("enabled, rollout_percentage")
    .eq("key", key)
    .maybeSingle();

  // Fail safe: an unknown or errored flag defaults to "off",
  // not "on" — a missing flag should never accidentally expose
  // an unfinished feature to everyone.
  if (error || !data || !data.enabled) {
    return false;
  }

  // No user context (e.g. a public page) — just use the master switch.
  if (!userId) {
    return data.rollout_percentage >= 100;
  }

  return isInRollout(userId, key, data.rollout_percentage);
}

What's happening here: this function is the single place that knows how to read a flag — every page, Server Action, or Route Handler in your app calls through here instead of querying Supabase directly. Notice the fail-safe default: if the flag doesn't exist, or the database call errors out, we return false. That's a deliberate choice — a flag failing "closed" (off) is almost always safer than failing "open" (on), since an unexpected true could expose an unfinished feature to every user.

Caching Feature Flag Reads with `next/cache`

Right now, getFeatureFlag() hits Supabase on every single call. If a flag is checked on a high-traffic page — or several times per request, once per feature — that's a lot of avoidable database round trips for data that barely changes. A hand-rolled in-memory cache can fix that, but it comes with real downsides in production: it only lives inside one serverless function instance (so different instances can disagree), and it disappears completely on every cold start or redeploy. Next.js already ships a caching layer built for exactly this — reach for that instead of reinventing it.

The good news: the shared part of a flag (its enabled state and rollout_percentage) is identical for every user. Only the final true/false decision is per-user, and that part is just cheap in-memory hashing. So you only need to cache the database row, not the per-user result.

Caching the flag row

// lib/flags/get-flag.ts
import { cacheLife, cacheTag } from "next/cache";
import { supabaseAdmin } from "@/lib/supabase/service-client";
import { isInRollout } from "./rollout";

type FlagRow = { enabled: boolean; rollout_percentage: number };

async function fetchFlagRow(key: string): Promise<FlagRow | null> {
  "use cache";
  cacheLife("minutes"); // safety-net expiry if nothing ever invalidates it
  cacheTag(`feature-flag:${key}`); // lets us invalidate just this one flag

  const { data, error } = await supabaseAdmin
    .from("feature_flags")
    .select("enabled, rollout_percentage")
    .eq("key", key)
    .maybeSingle();

  return error ? null : data;
}

export async function getFeatureFlag(
  key: string,
  userId?: string
): Promise<boolean> {
  const row = await fetchFlagRow(key);

  if (!row || !row.enabled) return false;
  if (!userId) return row.rollout_percentage >= 100;

  return isInRollout(userId, key, row.rollout_percentage);
}

What's happening here: "use cache" at the top of fetchFlagRow marks that function as a cache boundary — Next.js automatically derives the cache key from the function's arguments (key), so each flag gets its own independent cache entry with no manual key-building required. cacheLife("minutes") applies one of Next.js's built-in expiry profiles as a fallback expiry (a handful of minutes), in case nothing ever explicitly invalidates it. cacheTag(\feature-flag:${key}`)` is the important part for production use — it lets you invalidate exactly one flag on demand instead of waiting for the fallback expiry or flushing every cached flag at once.

💡 Tip: "use cache" requires Cache Components to be enabled in next.config.ts:
const nextConfig: NextConfig = {
  cacheComponents: true,
};
If your project isn't on Cache Components yet, use the older unstable_cache API instead — same tagging idea, just a wrapper function instead of a directive:
import { unstable_cache } from "next/cache";

const fetchFlagRow = (key: string) =>
  unstable_cache(
    async () => {
      const { data, error } = await supabaseAdmin
        .from("feature_flags")
        .select("enabled, rollout_percentage")
        .eq("key", key)
        .maybeSingle();
      return error ? null : data;
    },
    ["feature-flag", key],
    { tags: [`feature-flag:${key}`], revalidate: 60 }
  )();

Invalidating a flag the moment it changes

Caching only pays off if flipping a flag actually takes effect quickly. Instead of waiting out cacheLife's fallback window, invalidate the specific tag the moment an admin updates the row:

// actions/toggle-feature-flag.ts
"use server";

import { revalidateTag } from "next/cache";
import { supabaseAdmin } from "@/lib/supabase/service-client";

export async function toggleFeatureFlag(key: string, enabled: boolean) {
  const { error } = await supabaseAdmin
    .from("feature_flags")
    .update({ enabled, updated_at: new Date().toISOString() })
    .eq("key", key);

  if (error) {
    return { error: error.message };
  }

  // Instantly invalidates only this flag's cached row — every
  // subsequent getFeatureFlag() call re-fetches fresh data.
  revalidateTag(`feature-flag:${key}`);

  return { success: true };
}

What's happening here: revalidateTag(\feature-flag:${key}`) tells Next.js's cache "anything tagged with this string is now stale" — the very next call to fetchFlagRow(key) skips the cache and re-fetches from Supabase, then caches the fresh result under the same tag. This is what makes a cached flag system still behave like an instant kill switch: the cache saves you database round trips on the read path, while revalidateTag` guarantees a write is reflected immediately, not after some fixed delay.

⚠️ Common Mistake: Updating the feature_flags table directly from the Supabase dashboard and expecting the change to show up right away. The cache has no way to know the row changed unless something calls revalidateTag() — always flip flags through a path (like the Server Action above) that revalidates the tag, or expect to wait out the cacheLife window.

Step 4: Use the Flag in a Server Component

// app/dashboard/page.tsx
import { getFeatureFlag } from "@/lib/flags/get-flag";
import { getCurrentUser } from "@/lib/auth"; // whatever your auth setup returns
import { NewDashboard } from "@/components/dashboard/new-dashboard";
import { OldDashboard } from "@/components/dashboard/old-dashboard";

export default async function DashboardPage() {
  const user = await getCurrentUser();
  const showNewDashboard = await getFeatureFlag("new-dashboard", user?.id);

  return showNewDashboard ? <NewDashboard /> : <OldDashboard />;
}

What's happening here: because DashboardPage is an async Server Component, we can await getFeatureFlag(...) directly during render — no loading spinner, no client-side fetch, no flicker between the two versions. The flag is resolved once, on the server, before any HTML reaches the browser.

Step 5: Use the Same Flag in a Server Action

Flags aren't just for showing/hiding UI — sometimes you want to gate a whole action, like a new AI feature that costs you money per call.

// actions/generate-summary.ts
"use server";

import { getFeatureFlag } from "@/lib/flags/get-flag";
import { getCurrentUser } from "@/lib/auth";

export async function generateSummary(text: string) {
  const user = await getCurrentUser();

  if (!user) {
    return { error: "You must be signed in." };
  }

  const enabled = await getFeatureFlag("ai-summary", user.id);

  if (!enabled) {
    return { error: "This feature isn't available yet." };
  }

  // ... call your AI provider here
  return { summary: "..." };
}

What's happening here: re-checking the flag inside the Server Action matters even though the button that triggers it is already hidden by the flag in the UI. A hidden button doesn't stop someone from calling the Server Action directly — the server-side check is your real gate, the UI check is just for user experience.

⚠️ Common Mistake: Only checking a flag in the UI (hiding a button) and assuming that's enough. Server Actions are callable endpoints under the hood — always re-verify anything sensitive on the server, the same way you would with authentication or authorization checks.

Part 2: Using the Vercel Flags SDK

The do-it-yourself version above works fine, but as your flag list grows you'll want a few things it doesn't give you: a typed, centralized list of every flag in your app, a way to preview flag values locally without touching the database, and a consistent pattern if you ever want to swap in a dedicated flag provider later.

That's exactly what the Flags SDK (built by the Vercel/Next.js team) solves. It's free, open source, framework-native for Next.js, and — importantly — it works with any data source, including the Supabase table you just built. You're not locked into a specific vendor.

Step 1: Install the SDK

npm install flags

Step 2: Generate a Flags Secret

The SDK uses a secret key to encrypt flag values when they're referenced by its local override tooling. Generate one with Node:

node -e "console.log(crypto.randomBytes(32).toString('base64url'))"

Copy the output into your environment variables:

# .env.local
FLAGS_SECRET=your-generated-secret-here

💡 Tip: Use a different FLAGS_SECRET value for each environment (development, preview, production). If you're deploying on Vercel, set each one with vercel env add FLAGS_SECRET production --sensitive.

Step 3: Define Your Flags in One File

This is the part that makes the SDK worth using — every flag in your app is declared once, as a typed function, in a single file.

// flags.ts
import { flag } from "flags/next";
import { getFeatureFlag } from "@/lib/flags/get-flag";
import { getCurrentUser } from "@/lib/auth";

export const newDashboardFlag = flag<boolean>({
  key: "new-dashboard",
  description: "Show the redesigned dashboard layout",
  decide: async () => {
    const user = await getCurrentUser();
    return getFeatureFlag("new-dashboard", user?.id);
  },
});

export const aiSummaryFlag = flag<boolean>({
  key: "ai-summary",
  description: "AI-generated summary panel (early rollout)",
  decide: async () => {
    const user = await getCurrentUser();
    return getFeatureFlag("ai-summary", user?.id);
  },
});

What's happening here: flag() wraps each feature into its own reusable, typed function. Notice the decide function is just calling the exact same getFeatureFlag() helper you already built in Part 1 — the SDK doesn't replace your data source, it sits on top of it. This means you get the SDK's developer experience (typed flags, the local toolbar, easy provider swaps later) while still owning your data in Supabase.

💡 Tip: Turning every flag into its own exported function means your editor's "Find All References" feature works — you can instantly see every place a flag is used, and confidently delete it once it's no longer needed.

Step 4: Use a Flag in a Page

// app/dashboard/page.tsx
import { newDashboardFlag } from "@/flags";
import { NewDashboard } from "@/components/dashboard/new-dashboard";
import { OldDashboard } from "@/components/dashboard/old-dashboard";

export default async function DashboardPage() {
  const showNewDashboard = await newDashboardFlag();

  return showNewDashboard ? <NewDashboard /> : <OldDashboard />;
}

What's happening here: calling newDashboardFlag() runs the decide function you defined in flags.ts and returns the resolved boolean. Notice there are no arguments at the call site — the flag function already knows how to figure out the current user internally. This is intentional: it keeps every call site simple and makes flags easy to reason about, since the logic for how a flag is decided lives in exactly one place.

⚠️ Common Mistake: Trying to call a flag function from a Client Component. Flags SDK flags are server-only by design — this avoids client-side loading spinners and keeps the decision logic (which might touch a database or user session) off the browser entirely. If a Client Component needs the value, resolve it in the parent Server Component and pass it down as a prop.

Step 5: Conditionally Render a Client Component

// app/dashboard/page.tsx
import { aiSummaryFlag } from "@/flags";
import { SummaryPanel } from "@/components/dashboard/summary-panel";

export default async function DashboardPage() {
  const showAiSummary = await aiSummaryFlag();

  return (
    <div className="space-y-6">
      <h1 className="text-2xl font-semibold">Dashboard</h1>
      {showAiSummary && <SummaryPanel />}
    </div>
  );
}

// components/dashboard/summary-panel.tsx
"use client";

export function SummaryPanel() {
  // Interactive logic here — the flag decision already
  // happened on the server before this component ever rendered.
  return (
    <div className="rounded-xl border p-4">
      <p className="text-sm text-muted-foreground">AI summary coming soon…</p>
    </div>
  );
}

What's happening here: the Server Component resolves the flag once and only renders <SummaryPanel /> at all if the flag is on. The Client Component itself never needs to know a flag exists — it just renders when it's asked to. This keeps the flag-checking logic entirely on the server, which is both simpler and safer than shipping the flag's raw value to the browser.

Best Practices for Feature Flags

A handful of habits that keep a growing flag system from turning into a mess:

Name flags consistently. Use a predictable pattern like kebab-case with a type hint, e.g. release-new-checkout, experiment-pricing-copy, ops-disable-emails, permission-ai-summary. It makes a flag's purpose obvious at a glance.
Default to "off" everywhere. As shown in getFeatureFlag(), an unknown, missing, or errored flag should resolve to false. Fail closed, not open.
Delete flags once they've served their purpose. A release flag that's been at 100% for a month and never gets turned off isn't a flag anymore — it's just a permanent if statement adding complexity. Remove it and the dead code branch behind it.
Never gate real security on a flag alone. A feature flag controls visibility, not authorization. Someone technically could still reach a hidden feature by calling the underlying Server Action or API route directly — always pair a flag with a real permission check for anything sensitive (see Step 5 in Part 1).
Test both states. Before shipping, manually verify your app behaves correctly with the flag both on and off — it's easy to only test the "on" path and forget the fallback still needs to work.
Keep the rollout logic deterministic. As covered in Part 1, a user should see a consistent experience across requests, not a coin flip on every page load.

     Create
       ↓
    Develop
       ↓
Internal Testing
       ↓
       5%
       ↓
      25%
       ↓
      50%
       ↓
     100%
       ↓
    Delete

Frequently Asked Questions

Do I need a third-party service like LaunchDarkly to use feature flags?

No. A single database table, like the feature_flags table built in Part 1, is enough for most SaaS apps — especially early on. Third-party feature flag platforms add real value once you need advanced targeting rules, detailed analytics per flag, or a non-technical team managing flags through a dashboard, but they're not a requirement to get started.

What's the difference between a feature flag and an environment variable?

An environment variable is set at build or deploy time and requires a redeploy to change. A feature flag is checked at runtime and can be flipped instantly without touching your deployment — that's the whole point. Use environment variables for configuration (API keys, database URLs) and feature flags for behavior that needs to change without a redeploy.

Can I use feature flags for A/B testing?

Yes — this is one of the most common uses. Instead of a simple on/off boolean, an experiment flag typically returns one of several variants (e.g. "control" or "variant-b"), and you track which variant a user saw alongside your analytics events to measure the difference in behavior.

Do feature flags have to be true/false?

No — boolean is just the simplest case. Many production flags are multivariate: instead of resolving to true/false, they resolve to one of several named values, like "control", "variant-a", or "variant-b". This is what powers most pricing, copy, and layout experiments, where you're comparing more than two options at once. The pattern in this guide extends naturally — swap the enabled boolean column for a value column (text or jsonb), and type your Flags SDK flag as flag<string>({...}) instead of flag<boolean>({...}) so decide() returns the variant name instead of a boolean. Everything else — the deterministic bucketing, the caching, the server-only checks — works exactly the same way.

Are feature flags secure enough to gate paid features?

A flag can decide whether to show a paid feature, but it should never be the only check. Always verify the user's actual subscription/permission status on the server (inside the Server Action or API route that does the real work) — the flag is a UX layer on top of that, not a replacement for it.

How many feature flags is too many?

There's no hard number, but if you regularly can't remember what a flag does or find yourself afraid to delete one, that's a sign your flag list needs cleanup. A good habit is reviewing flags monthly and removing any release flag that's been fully rolled out and stable for a few weeks.

Does checking a flag slow down my page?

If you're checking the same flags on every request, the Next.js caching approach from the Caching Feature Flag Reads with next/cache section removes most of that cost while still allowing immediate invalidation with revalidateTag().

Wrapping Up

Feature flags turn deployment and release into two separate decisions — you can ship code to production without exposing it, roll features out gradually, and flip a broken feature off in seconds instead of scrambling through a redeploy. You've now got two working approaches: a simple, fully self-owned system backed by a Supabase table, and the Vercel Flags SDK layered on top of it for a more polished, typed developer experience.

Start small — pick one risky upcoming feature, put it behind a flag using the Part 1 pattern, and get comfortable with the workflow before rolling flags out across your whole app.

Continue Learning

How Should You Structure a Software Architecture?

Fri, 21 Aug 2026 17:30:58 +0000

Hey developers! 👋

Welcome back to the journey from business requirements to production-ready systems.

A founder walks into a development team and says:

"We need an ERP."

Sounds simple.

Until you start asking questions.

Where should users live?

How should organizations work?

Who owns inventory?

Where should orders be created?

Who is allowed to approve invoices?

What happens when thousands of users start using the dashboard?

Where should business rules live?

Should everything be one application?

Should we use microservices?

And eventually:

How do we build today's system without making tomorrow's system painful to change?

That's where software architecture begins.

Not with Kubernetes.

Not with Kafka.

Not with microservices.

Not even with Django vs FastAPI.

It begins with understanding what the business actually needs to do.

Let's build the architecture from that starting point.

The First Mistake: Starting With Technology

Imagine the product team gives you an ERP requirement.

A common engineering conversation might immediately become:

Django or FastAPI?

PostgreSQL or MongoDB?

Redis?

Kafka?

RabbitMQ?

Kubernetes?

Microservices?

These are valid questions.

But they're not the first questions.

The first question is:

What responsibilities does this business actually have?

An ERP might need:

ERP
│
├── Identity
├── Organizations
├── Products
├── Inventory
├── Sales
├── Purchasing
├── Billing
├── Reporting
└── Notifications

Notice something important.

These aren't technologies.

They're business capabilities.

That distinction changes how we design the entire system.

Step 1: Discover the Business Capabilities

Start by talking about what the system does.

For example:

The business needs to:

Manage employees
Manage organizations
Track products
Track inventory
Create sales orders
Handle purchasing
Generate invoices
Process payments
Produce reports
Send notifications

Now the system has a shape.

Instead of starting with:

controllers/
models/
views/
utils/
helpers/
services/

we can start with:

identity/
organization/
inventory/
sales/
purchasing/
billing/
reporting/

Why is this useful?

Because someone joining the project six months later can understand the product by looking at its structure.

The code starts reflecting the business.

And that's a powerful architectural principle:

Organize around meaningful responsibilities before organizing around technical abstractions.

Step 2: Find the Boundaries

Identifying capabilities isn't enough.

We also need to determine where one responsibility ends.

Consider an order.

An order depends on products.

Inventory also depends on products.

Billing depends on orders.

Reporting may depend on almost everything.

If every module directly knows about every other module, we eventually get something like:

Sales ───────► Inventory
  │              │
  ▼              ▼
Billing ◄──── Products
  │              │
  └──────► Reporting
       ▲
       │
   Identity

At first, this feels convenient.

Need something from another module?

Just import it.

But eventually:

Change Inventory
      ↓
Break Sales
      ↓
Break Reporting
      ↓
Fix Five Other Modules

The problem isn't that the system has many modules.

The problem is that the responsibilities aren't properly isolated.

A healthier model is:

Identity
   │
   └── Who is this user?

Organization
   │
   └── Which business does the user belong to?

Inventory
   │
   └── What resources do we have?

Sales
   │
   └── What are we selling?

Purchasing
   │
   └── What are we buying?

Billing
   │
   └── What do we charge?

Reporting
   │
   └── What happened?

Each area has a reason to exist.

That's what a boundary should accomplish.

A boundary is not just a folder. It defines ownership.

Step 3: Architecture Is About Ownership

Let's take a very normal operation:

A customer places an order.

From the outside:

POST /orders

Looks simple.

Internally, it could involve:

Authenticate User
      ↓
Resolve Organization
      ↓
Check Membership
      ↓
Authorize Action
      ↓
Validate Request
      ↓
Validate Products
      ↓
Check Inventory
      ↓
Calculate Price
      ↓
Apply Discount
      ↓
Create Order
      ↓
Update Inventory
      ↓
Create Financial Records
      ↓
Record Audit Event
      ↓
Trigger Notifications

A beginner might put all of this inside:

CreateOrderView

Something like:

CreateOrderView
│
├── authenticate()
├── authorize()
├── validate()
├── check_inventory()
├── calculate_price()
├── apply_discount()
├── create_order()
├── update_inventory()
├── create_invoice()
├── write_audit()
├── send_email()
└── response()

It works.

Until the application grows.

The API layer slowly becomes the place where the entire business lives.

That's when architecture starts becoming difficult to maintain.

A better separation looks like:

HTTP Request
     │
     ▼
API Layer
     │
     ▼
Application Service
     │
     ▼
Domain Rules
     │
     ▼
Persistence
     │
     ▼
Database

Now each layer has a different responsibility.

API Layer

Understands:

HTTP
Requests
Responses
Status Codes
Serialization

Application Service

Understands:

What use case are we executing?

Domain Logic

Understands:

What rules must always remain true?

Persistence

Understands:

How do we read and write data?

Database

Protects:

Data integrity
Constraints
Transactions
Indexes
Relationships

The objective isn't more layers.

The objective is clear ownership.

Follow the Request Instead of Staring at the Diagram

Architecture diagrams can become abstract very quickly.

A better way to understand a system is to follow an actual request.

Imagine the user clicks:

Create Order

The request could travel through:

Client
  │
  ▼
API
  │
  ▼
Authentication
  │
  ▼
Authorization
  │
  ▼
Validation
  │
  ▼
CreateOrderService
  │
  ├── Product Validation
  ├── Inventory Check
  ├── Price Calculation
  └── Order Creation
  │
  ▼
Database Transaction
  │
  ▼
Order Created
  │
  ▼
Domain Event
  │
  ├── Audit
  ├── Notification
  └── Analytics

Now architecture becomes easier to reason about.

Every component has a purpose.

This gives us another useful rule:

If you cannot explain why a component exists in the request journey, question whether you need that component.

Turning Boundaries Into Code

Once the business boundaries are clear, we can map them into the project.

For example:

backend/
│
├── apps/
│   │
│   ├── identity/
│   │   ├── models/
│   │   ├── services/
│   │   ├── permissions/
│   │   └── api/
│   │
│   ├── organization/
│   │   ├── models/
│   │   ├── services/
│   │   ├── permissions/
│   │   └── api/
│   │
│   ├── inventory/
│   │   ├── models/
│   │   ├── services/
│   │   ├── repositories/
│   │   └── api/
│   │
│   ├── sales/
│   │   ├── models/
│   │   ├── services/
│   │   ├── repositories/
│   │   └── api/
│   │
│   ├── purchasing/
│   ├── billing/
│   └── reporting/
│
├── shared/
│   ├── authentication/
│   ├── authorization/
│   ├── exceptions/
│   ├── logging/
│   └── utilities/
│
├── infrastructure/
│   ├── database/
│   ├── cache/
│   ├── messaging/
│   ├── storage/
│   └── email/
│
└── config/

The important part isn't the exact folder names.

It's the reasoning behind them.

We didn't say:

"Every application needs repositories."

We first asked:

"What are the responsibilities?"

Then we created a structure that reflects those responsibilities.

What Belongs Inside a Module?

Let's zoom into sales.

A possible module might look like:

sales/
│
├── models/
├── services/
├── repositories/
├── permissions/
├── events/
├── validators/
└── api/

But folders alone don't create architecture.

Each part needs a purpose.

API

The API is the system's external boundary.

It handles:

HTTP Requests
Validation Input
Serialization
HTTP Responses
Status Codes

It translates external communication into application operations.

It should not become the entire business engine.

Application Services

Services should represent meaningful operations.

For example:

CreateOrderService
ConfirmOrderService
CancelOrderService
RefundOrderService

A useful question is:

What business operation does this service represent?

If the answer is unclear, the abstraction may not be useful.

Domain Logic

This is where business rules belong.

For example:

An order cannot be cancelled after shipment.

Inventory cannot become negative.

A finalized invoice cannot be edited.

Only an authorized organization owner can transfer ownership.

These aren't HTTP concepts.

They're business rules.

They should remain as independent from the delivery mechanism as practical.

Persistence

Persistence handles data access.

For example:

find_order()
find_product()
save_order()
get_inventory()

Its responsibility is retrieving and storing information.

It shouldn't decide:

"Is this customer allowed to cancel the order?"

That's a business decision.

Don't Turn Everything Into a Service

There's another architectural trap.

Once developers discover service classes, everything becomes a service:

UserService
ProductService
OrderService
EmailService
DatabaseService
ValidationService
HelperService
ManagerService
UtilsService

Soon the codebase has hundreds of abstractions.

But abstraction isn't automatically architecture.

The objective isn't:

More classes.

It's:

Clearer responsibilities.

Before introducing a service, ask:

What meaningful business capability or use case does this component represent?

Architecture should reduce cognitive load.

Not create another maze for developers to navigate.

The Database Is Not "Just Storage"

One of the biggest architectural mistakes is treating the database as a passive storage box.

For business systems, the database is part of the architecture.

Take inventory.

A simplistic model might store:

Product
quantity = 500

But where did those 500 units come from?

Maybe:

Purchase
Sale
Return
Transfer
Adjustment
Damage

If we only store the current number, we've lost the history.

A stronger model records inventory movements:

Product
   │
   ▼
Inventory Movement
   │
   ├── Purchase
   ├── Sale
   ├── Return
   ├── Adjustment
   └── Transfer

Now the system can answer two very different questions:

How much inventory do we have?

and:

Why do we have this amount?

That second question becomes critical for:

auditing
reconciliation
reporting
debugging
financial accuracy

So database architecture is more than:

API → Database

It is closer to:

Business Rules
      ↓
Data Model
      ↓
Transactions
      ↓
Constraints
      ↓
Indexes
      ↓
Persistence

A good data model doesn't merely store information.

It helps protect the business.

Transactions: Keeping Business Operations Consistent

Consider order creation.

We may need to perform:

Create Order
Reduce Inventory
Create Financial Record

Now imagine:

Order       → Success
Inventory   → Success
Financials  → Failure

The system is inconsistent.

The order exists.

Inventory changed.

But the financial record didn't.

For operations that must succeed or fail together, we need a transactional boundary:

Transaction
│
├── Create Order
├── Update Inventory
└── Create Financial Record

Either:

Everything succeeds

or:

Everything rolls back

But there's an important architectural distinction.

Not every operation belongs inside the transaction.

Sending an email doesn't normally need to hold the database transaction open.

Generating a large PDF doesn't either.

Sending analytics data may not need to block the user.

That leads naturally to asynchronous processing.

Some Work Should Happen Later

Imagine a user creates an order.

Do they really need to wait while the system:

Send Email
Generate PDF
Update Analytics
Notify Warehouse
Sync External System

Probably not.

The user mainly needs one answer:

Was my order created successfully?

So the system can separate critical work from background work:

Create Order
     │
     ▼
Database Transaction
     │
     ▼
Order Created
     │
     ▼
Return Response

Then:

Order Created Event
        │
        ├── Send Email
        ├── Generate Invoice
        ├── Update Analytics
        ├── Notify Warehouse
        └── Sync External System

Queues and workers become useful here.

But notice the reasoning.

We didn't begin with:

"Let's install RabbitMQ."

We began with:

"Which work should not block the user's request?"

That's the architectural decision.

Synchronous vs Asynchronous Processing

A simple rule of thumb:

Keep work synchronous when:

the user needs the result immediately
the operation is relatively fast
immediate consistency matters

For example:

Create Order
Validate Payment
Update Inventory

Consider asynchronous processing when:

the operation is slow
the user doesn't need the result immediately
it can be retried
an external system is involved
the work is computationally expensive

For example:

Generate Large Report
Send Bulk Emails
Export Millions of Records
Process Large Files
Synchronize External Data

The lesson isn't:

"Always use queues."

It's:

Choose synchronous or asynchronous processing based on the characteristics of the work.

Authentication Isn't Authorization

As the ERP grows, we need to know who is making a request.

That's authentication.

But identity alone isn't enough.

We also need to know what that person can do.

That's authorization.

A typical enterprise request might look like:

User
  ↓
Organization Membership
  ↓
Role
  ↓
Permissions

For example:

A manager might have:

invoice.view
invoice.create
inventory.view
inventory.adjust

While another employee may only have:

inventory.view
order.create

So remember:

Authentication asks:

Who are you?

Authorization asks:

What are you allowed to do?

Those are different architectural concerns.

Multi-Tenancy Changes Everything

Now let's turn our ERP into a SaaS platform.

Instead of one company, we have:

Organization A
Organization B
Organization C
...
Organization 500

The security question changes.

It is no longer simply:

Can this user access this order?

It becomes:

Can this user, inside this organization, perform this action on this resource?

The request might therefore follow:

Request
   ↓
Authenticate User
   ↓
Resolve Organization
   ↓
Verify Membership
   ↓
Authorize Action
   ↓
Query Tenant-Scoped Data

The database should reinforce this boundary.

For example:

Order
│
├── id
├── organization_id
├── customer_id
└── total

Now the order belongs to a specific organization.

This is more than a feature.

Tenant isolation is an architectural security boundary.

A failure here can expose one customer's information to another customer.

That's why multi-tenancy should be considered during architectural design, not bolted on later.

APIs Are Contracts, Not Just Endpoints

The internal architecture may change many times.

Clients shouldn't need to know about those internal changes.

A web application shouldn't care whether the backend uses:

PostgreSQL
Redis
Workers
A Monolith
Microservices
A Message Broker

It should communicate through a stable contract:

Web App
     │
Mobile App
     │
Partner
     │
Internal Tool
     │
     ▼
    API
     │
     ▼
Application

That's why API design matters.

An API is a contract between:

clients
developers
internal teams
partners
future products

A strong API allows internal implementation to evolve without forcing every consumer to understand the internal architecture.

Then Reality Happens: Performance Problems

Eventually the ERP grows.

The dashboard becomes popular.

A request such as:

GET /dashboard

might perform:

20 database queries
3 aggregations
5 joins
2 external requests

Now thousands of users hit the same endpoint.

The database becomes a bottleneck.

The obvious response might be:

"Add more database servers."

But first ask:

Are we calculating the same information repeatedly?

If yes, caching might help.

Request
   │
   ▼
Cache
   │
   ├── Hit ──────► Response
   │
   └── Miss
        │
        ▼
     Database
        │
        ▼
    Store Cache
        │
        ▼
     Response

But caching creates new architectural questions:

How long should data remain cached?

When should it expire?

When should it be invalidated?

Is stale data acceptable?

What happens if the cache is unavailable?

What information is safe to cache?

So don't add a cache because:

"Scalable systems use Redis."

Add caching because:

A measured workload shows that caching solves a real problem.

Observability: When Production Starts Talking

Eventually someone will tell you:

"The API is slow."

Now what?

You need to answer:

Which endpoint?

Which request?

Which user?

Which organization?

How long did it take?

Which database query was slow?

Was it a cache miss?

Did the queue become overloaded?

Did an external service fail?

That's observability.

A useful request context might include:

request_id
user_id
organization_id
endpoint
status
duration

And the three familiar pillars are:

Logs
Metrics
Traces

Logs

Tell you what happened.

Metrics

Tell you how frequently and severely something is happening.

Traces

Show where time was spent across a request.

Without observability, production debugging becomes:

Something is slow.

Something is broken.

Maybe restart the server?

That's not an architecture strategy.

Infrastructure Comes After the Application

Only after understanding the application should infrastructure decisions become concrete.

A reasonable production starting point might look like:

                    Internet
                       │
                       ▼
                 Load Balancer
                       │
                       ▼
                   API Servers
                  /     |      \
                 /      |       \
                ▼       ▼        ▼
          PostgreSQL   Redis   Object Storage
                           │
                           ▼
                      Message Queue
                           │
                           ▼
                         Workers

Around that system:

CI/CD
Monitoring
Logging
Tracing
Backups
Secrets Management
Alerts

Now each component has a reason.

PostgreSQL       → business data
Redis            → selected fast-access workloads
Object Storage   → files
Message Queue    → asynchronous coordination
Workers          → background processing
Monitoring       → system health
CI/CD            → safe delivery

This is much healthier than creating a diagram with 25 technologies first and then trying to invent reasons for them.

Should You Start With Microservices?

Eventually, someone will probably say:

"We should use microservices."

Maybe.

But let's look at the context.

Suppose the company has:

5 Developers
1 Product
10 Customers

And we introduce:

User Service
Product Service
Order Service
Inventory Service
Billing Service
Notification Service
API Gateway
Service Mesh
Message Broker
Kubernetes

It looks sophisticated.

But now a simple feature might require:

Multiple Services
Multiple Deployments
Network Communication
Service Authentication
Distributed Debugging
Event Coordination

We've created a distributed system before we actually had a distributed problem.

The architecture is now more complicated than the business.

A simpler starting point could be:

                 Modular Monolith
                       │
          ┌────────────┼────────────┐
          ▼            ▼            ▼
       Identity     Inventory      Sales
          │            │            │
          └────────────┼────────────┘
                       ▼
                   PostgreSQL

Everything can still deploy together.

But the boundaries remain explicit.

That's important.

Simple deployment does not have to mean chaotic architecture.

Modular Monolith vs Microservices

A modular monolith doesn't mean:

"We will never use microservices."

It means:

"We will introduce distribution when distribution solves a real problem."

The evolution can look like:

Modular Monolith
       │
       ▼
Identify Bottleneck
       │
       ▼
Find the Right Boundary
       │
       ▼
Extract One Capability
       │
       ▼
Independent Service

Suppose reporting becomes extremely expensive.

Instead of splitting everything:

Identity
Sales
Inventory
Billing
Reporting
Notifications

we might extract only reporting:

Main Application
│
├── Identity
├── Sales
├── Inventory
└── Billing

        +

Reporting Service

Now reporting can scale independently.

We didn't distribute the entire company.

We distributed the capability that actually needed it.

Architecture Should Have an Evolution Path

A system doesn't need its final architecture on day one.

It might begin as:

API
 │
 ▼
Application
 │
 ▼
PostgreSQL

Traffic increases:

API
 │
 ▼
Application
 │
 ├── PostgreSQL
 └── Redis

Background workloads grow:

API
 │
 ▼
Application
 │
 ├── PostgreSQL
 ├── Redis
 └── Workers

Asynchronous workflows become more complex:

API
 │
 ▼
Application
 │
 ├── PostgreSQL
 ├── Redis
 ├── Message Bus
 └── Workers

Eventually, perhaps one capability becomes independently scalable:

                 API Gateway
                      │
          ┌───────────┼───────────┐
          ▼           ▼           ▼
        Sales      Inventory    Billing
          │           │           │
          └───────────┼───────────┘
                      ▼
                Event Platform

The important part isn't the final diagram.

It's the journey between the diagrams.

Good architecture is an evolution path, not a perfect diagram created on day one.

Five Questions Before Adding Complexity

Before introducing another architectural component, ask five questions.

1. What problem are we solving?

Don't begin with:

"Should we use Kafka?"

Begin with:

"What problem are we experiencing?"

2. Who should own this responsibility?

Ask:

"Which module should own this behavior?"

Ownership prevents responsibility from leaking everywhere.

3. Does this need to happen immediately?

Ask:

"Does the user need the result before the request finishes?"

If not, asynchronous processing may be appropriate.

4. What happens as the system grows?

Ask:

"Could this component become a bottleneck or coupling point?"

5. What does this component cost operationally?

Every new component creates work.

A new service can mean:

Deployment
Monitoring
Networking
Authentication
Debugging
Failure Handling
Documentation
Ownership

Architecture isn't free.

Every abstraction has a maintenance cost.

Every distributed component creates another possible failure boundary.

So good architects don't only ask:

"Can we add this?"

They ask:

"Do we actually need this?"

The Architecture I'd Start With

If I were starting a SaaS or ERP platform today, I wouldn't begin with a giant distributed architecture.

I'd start closer to:

                  Client Applications
                          │
                          ▼
                       API Layer
                          │
                          ▼
                  Modular Application
                          │
          ┌───────────────┼───────────────┐
          ▼               ▼               ▼
       Identity        Inventory         Sales
          │               │               │
          ├───────────────┼───────────────┤
          │               │               │
          ▼               ▼               ▼
       Billing        Purchasing      Reporting
                          │
                          ▼
                      PostgreSQL
                          │
                    ┌─────┴─────┐
                    ▼           ▼
                  Redis       Workers
                                │
                                ▼
                           Message Queue

Alongside it:

Authentication
Authorization
Tenant Isolation
Transactions
Structured Logging
Metrics
Tracing
CI/CD
Backups

And deliberately avoid introducing:

Microservices
Service Mesh
Kubernetes
Distributed Databases
Complex Event Platforms

until the product actually gives you a reason.

These technologies aren't bad.

The principle is simpler:

Complexity should be earned by the problem.

Production Architecture Checklist

Before calling an architecture production-ready, ask:

Business

Do we understand the business capabilities?
Are responsibilities clearly separated?
Do modules represent meaningful business boundaries?

Application

Is business logic separated from HTTP concerns?
Are use cases easy to identify?
Are dependencies understandable?
Can modules evolve independently where appropriate?

Data

Does the data model reflect business requirements?
Are important invariants protected?
Are transactions used correctly?
Are indexes based on real query patterns?
Is historical information preserved where necessary?

Security

Is authentication handled consistently?
Is authorization explicit?
Is tenant isolation enforced?
Are sensitive operations auditable?
Are secrets protected?

API

Are resources predictable?
Are responses consistent?
Are breaking changes controlled?
Is documentation available?
Is the API treated as a stable contract?

Performance

Is pagination implemented?
Are expensive queries optimized?
Is caching used where justified?
Can heavy work move to background processing?

Reliability

Are failures handled?
Can background jobs be retried safely?
Are critical operations idempotent where necessary?
Are backups available?
Can the system recover from dependency failures?

Observability

Can we trace requests?
Can we measure latency?
Can we identify errors?
Can we monitor database performance?
Can we understand queue and worker health?

Operations

Can we deploy safely?
Can we roll back?
Are secrets managed securely?
Are alerts configured?
Can engineers understand what's happening in production?

If you can't answer these questions, the architecture probably isn't finished.

The Architecture Mindset

After all of this, software architecture can sound complicated.

But the underlying process is surprisingly simple.

When designing a system, keep asking:

What is this system responsible for?

Then:

Who should own that responsibility?

Then:

How should that responsibility communicate with other parts of the system?

Then:

What data does it need?

Then:

What happens when something fails?

And finally:

What happens when the business becomes larger?

Those questions naturally lead to:

Business Requirements
        ↓
Business Capabilities
        ↓
Boundaries
        ↓
Modules
        ↓
Application Logic
        ↓
Data Architecture
        ↓
API Contracts
        ↓
Transactions
        ↓
Async Processing
        ↓
Security
        ↓
Observability
        ↓
Infrastructure
        ↓
Deployment

That's architecture.

Not the number of services.

Not the number of technologies.

Not how complicated the architecture diagram looks.

Beginner vs Senior Architecture Thinking

A beginner often asks:

"Which architecture should I use?"

A developer asks:

"How should I structure this project?"

A senior engineer asks:

"Where should this responsibility live?"

A CTO asks:

"How will this architecture affect the business six months from now?"

A strong architect eventually learns to ask all four.

Because the goal isn't to build the most sophisticated system.

The goal is to build something that is:

understandable today, maintainable tomorrow, and capable of evolving when the business changes.

Final Thoughts: Architecture Is a Journey 🧠

A business idea doesn't become a production system by adding more technologies.

It becomes a production system through a series of deliberate decisions.

First:

Understand the Business

Then:

Find the Responsibilities

Then:

Create Boundaries

Then:

Define Ownership

Then:

Protect the Data

Then:

Design the Contracts

Then:

Handle Failure

Then:

Measure the System

And only then:

Introduce Complexity When Necessary

That's the real progression.

Good architecture isn't about having more components.

It's about putting the right responsibility in the right place.

And perhaps the simplest way to remember it is:

Don't start with technology.

Start with the business.

Find the responsibilities.

Create the boundaries.

Define ownership.

Protect the data.

Design the interactions.

Plan for failure.

Measure the system.

Scale what actually needs scaling.

Then introduce complexity only when the problem earns it.

That's how a simple business idea becomes a production-ready software architecture.

Key Takeaways

Start architecture with business capabilities, not technologies.
Organize systems around responsibilities and ownership.
Use boundaries to prevent uncontrolled coupling.
Keep HTTP concerns separate from core business rules.
Treat the database as an architectural component.
Use transactions to protect operations that must succeed together.
Move appropriate workloads to asynchronous processing.
Separate authentication from authorization.
Treat tenant isolation as a security boundary.
Design APIs as stable contracts.
Add caching because a workload needs it, not because it's fashionable.
Build observability before production becomes difficult to debug.
Don't introduce microservices before you have a distributed problem.
Prefer a modular monolith when it provides enough structure for the current stage.
Design architecture as an evolution path, not a final diagram.
Every architectural component has an operational and maintenance cost.
Complexity should have a reason.

Estate AI by Pixel Perfects Solutions

Thu, 20 Aug 2026 21:01:10 +0000

Estate AI by Pixel Perfects Solutions

Estate AI by Pixel Perfects Solutions is an AI-powered virtual staging platform built for real estate professionals who want to create better property listings faster.

Transform empty or unfurnished room photos into realistic, professionally furnished spaces using AI — without the cost and time of traditional staging.

Key Features

AI-powered virtual staging
Multiple interior design styles
Realistic furniture placement
Preserves room architecture, walls, windows, and layout
Before-and-after image comparison
Multiple room types
Fast AI-generated results
Project history
Credit-based workflow
Free plan available

Built for Real Estate Professionals

Estate AI by Pixel Perfects Solutions is designed for:

Real estate agents
Realtors and brokers
Real estate photographers
Property developers
Home staging professionals
Property marketing teams
Real estate agencies

Why Estate AI?

Empty property photos can make listings feel cold and difficult for buyers to visualize. Estate AI helps real estate professionals turn those empty spaces into attractive, furnished visuals that can improve listing presentation and marketing workflows.

Start with the free plan and explore AI-powered virtual staging.

Website: https://estateai.pxlperfects.com/

Why API Architecture Is a Business Decision, Not a Technical One

Mon, 17 Aug 2026 14:45:57 +0000

Modern software products are API-driven businesses.

Whether building SaaS platforms, ERP systems, marketplaces, mobile applications, or internal enterprise software, nearly every business operation eventually becomes an API request.

Customers place orders through APIs.

Mobile applications consume APIs.

Partners integrate through APIs.

Automation workflows execute through APIs.

Future products are built on top of APIs.

As a result, API architecture is no longer just a backend implementation detail. It becomes one of the most important strategic decisions in software systems because it directly influences growth, scalability, operational efficiency, product velocity, and long-term maintenance costs.

The quality of an organization's API architecture often determines whether the platform becomes easier to evolve over time or increasingly difficult to change.

Executive Summary

Most discussions about APIs focus on endpoints, authentication mechanisms, request formats, or framework choices.

These topics are important.

However, they miss the larger picture.

API architecture defines how business capabilities are exposed, consumed, reused, secured, and evolved.

A well-designed API architecture creates:

Faster product delivery
Easier integrations
Better customer experience
Lower operational costs
Improved scalability
Stronger security
Better developer experience
Greater long-term flexibility

A poorly designed API architecture creates:

Feature bottlenecks
Integration friction
Engineering complexity
Repeated implementations
Platform inconsistency
Expensive rewrites
Operational inefficiencies

The difference between a software product and a software platform is often the quality of its API architecture.

The Real Problem

Most systems do not fail because of insufficient features.

They fail because the architecture cannot support growth.

Consider a business platform that contains:

User Management
Products
Inventory
Orders
Billing
Reporting
Notifications
Automation

Initially, development feels simple.

A frontend sends requests.

The backend processes them.

The database stores data.

Everything appears manageable.

Over time, however, new requirements emerge:

Mobile applications
Third-party integrations
Internal automation
Public APIs
Partner portals
Analytics systems
External marketplaces

Without a structured API architecture, complexity begins growing faster than business value.

Common symptoms appear:

Business logic duplication
Inconsistent interfaces
Difficult integrations
Expensive feature development
Slower releases
Rising maintenance costs

Eventually, the platform becomes harder to maintain than the business itself.

At this point, architecture becomes a business constraint.

Understanding APIs as Business Capabilities

Many systems are designed around screens.

Mature systems are designed around capabilities.

This distinction is critical.

Screen-oriented thinking often produces APIs like:

POST /create-product
GET /get-user-orders
POST /submit-payment

Capability-oriented thinking produces APIs like:

POST /products
GET /orders
POST /payments

The difference appears small.

The impact is enormous.

Capabilities can be reused.

Screens cannot.

A capability-oriented API allows multiple consumers to share the same business logic:

                Products API
                       │
      ┌────────────────┼────────────────┐
      ▼                ▼                ▼
   Web App        Mobile App      Partner API
      ▼                ▼                ▼
      └──────────── Same Capability ───┘

Instead of rebuilding functionality repeatedly, the system exposes reusable business capabilities that can support current and future products.

This transforms APIs from implementation details into long-term business assets.

The Cost of Architectural Debt

Most technical debt is visible.

API debt often remains hidden until scale arrives.

Stage 1: Initial Product

Frontend
    │
    ▼
Backend
    │
    ▼
Database

Simple.

Fast.

Easy to understand.

Stage 2: Additional Clients

Web
 │
 ▼

Backend
 │
 ▼
Database

Mobile
 │
 ▼
Backend

API quality now matters.

Multiple consumers depend on the same contract.

Stage 3: Integrations

Web App
Mobile App
Partner Systems
Internal Tools
Automation
       │
       ▼
    Backend
       │
       ▼
    Database

Inconsistencies become expensive.

Every integration requires additional effort.

Every change introduces risk.

Stage 4: Platform Scale

Customers
Partners
Vendors
Automation
Analytics
Future Products
        │
        ▼
     Platform

The architecture now influences every business initiative.

The cost of poor decisions compounds.

The value of good decisions compounds as well.

Architecture as an Execution Layer

Every business strategy eventually becomes software behavior.

Every software behavior eventually becomes an API interaction.

This makes APIs the execution layer between business goals and technical systems.

Business Objectives
         │
         ▼
Business Capabilities
         │
         ▼
API Contracts
         │
         ▼
Application Services
         │
         ▼
Infrastructure

When API architecture is designed well, new initiatives move quickly through this chain.

When API architecture is designed poorly, every initiative becomes slower, more expensive, and riskier.

High-Level Architecture Blueprint

A scalable API platform should separate concerns into distinct layers.

                    ┌─────────────────────┐
                    │    Client Layer     │
                    │ Web, Mobile, APIs   │
                    └──────────┬──────────┘
                               │
                               ▼
                    ┌─────────────────────┐
                    │     API Gateway     │
                    └──────────┬──────────┘
                               │
      ┌────────────────────────┼────────────────────────┐
      ▼                        ▼                        ▼

┌──────────────┐      ┌──────────────┐      ┌──────────────┐
│Authentication│      │ Authorization│      │ Rate Limiting│
└──────┬───────┘      └──────┬───────┘      └──────┬───────┘
       └─────────────────────┼─────────────────────┘
                             ▼

                 ┌─────────────────────────┐
                 │      Service Layer      │
                 │ Business Capabilities   │
                 └───────────┬─────────────┘
                             │
       ┌─────────────────────┼─────────────────────┐
       ▼                     ▼                     ▼

 ┌────────────┐      ┌────────────┐      ┌────────────┐
 │ PostgreSQL │      │ Redis      │      │ Message Bus│
 │ Source     │      │ Cache      │      │ Async Work │
 │ of Truth   │      │ Layer      │      │ Processing │
 └────────────┘      └────────────┘      └────────────┘

Each layer exists for a specific reason.

Authentication establishes identity.

Authorization enforces business rules.

Rate limiting protects resources.

Services execute business capabilities.

Databases persist information.

Caches improve performance.

Message queues enable scale.

The architecture remains understandable because responsibilities remain separated.

The Request Lifecycle

Every request should follow a predictable journey.

Client Request
      │
      ▼
API Gateway
      │
      ▼
Authentication
      │
      ▼
Authorization
      │
      ▼
Input Validation
      │
      ▼
Business Logic
      │
      ▼
Data Persistence
      │
      ▼
Response

A consistent lifecycle improves:

Security
Testing
Debugging
Monitoring
Maintainability
Reliability

Predictability becomes increasingly valuable as systems grow.

The Four Architectural Decisions That Shape Growth

1. API-First vs Interface-First

Many systems are designed around screens.

Scalable systems are designed around capabilities.

Interface-First

Screen
   │
   ▼
Backend Logic

API-First

Business Capability
         │
         ▼
         API
         │
 ┌───────┼────────┐
 ▼       ▼        ▼

Web   Mobile   Partner

The API-first approach creates reusable building blocks rather than isolated implementations.

2. Synchronous vs Event-Driven Processing

Not every operation should complete during a request.

Synchronous

Request
   │
   ▼
Process
   │
   ▼
Response

Simple.

But limited.

Event-Driven

Request
   │
   ▼
Queue Message
   │
   ▼
Worker
   │
   ▼
Background Processing

Ideal for:

Notifications
Emails
Reporting
Exports
Integrations
Audit Logs

This approach improves responsiveness while supporting growth.

3. Modular Monolith vs Distributed Systems

One of the most common mistakes is introducing complexity too early.

A well-structured modular monolith often provides:

Faster development
Easier debugging
Lower operational costs
Simpler deployments
Better maintainability

Application
│
├── Users Module
├── Orders Module
├── Inventory Module
├── Billing Module
└── Reporting Module

Strong internal boundaries usually provide more value than premature distribution.

4. APIs as Products

Many systems expose APIs.

Few treat them as products.

A product-quality API requires:

Consistency
Documentation
Reliability
Versioning
Security
Developer Experience

The API itself becomes part of the customer experience.

Versioning Strategy

Change is inevitable.

Breaking consumers is optional.

A versioning strategy allows systems to evolve safely.

/api/v1/products

/api/v2/products

Benefits include:

Backward compatibility
Safer deployments
Controlled migrations
Reduced disruption

Versioning is not merely a technical mechanism.

It is an operational stability strategy.

Authentication and Authorization

Authentication answers:

Who are you?

Authorization answers:

What are you allowed to do?

These concerns should remain separate.

A common authorization model is RBAC:

User
 │
 ▼
Role
 │
 ▼
Permissions

Example permissions:

invoice.create
invoice.view
inventory.adjust
user.invite

This structure scales naturally as systems become more complex.

Scalability Beyond Infrastructure

Scalability is often misunderstood.

Adding servers is infrastructure scaling.

Reducing architectural friction is system scaling.

Important scalability mechanisms include:

Pagination
Filtering
Search
Caching
Background processing
Rate limiting

For example:

GET /orders?page=1&page_size=50

is significantly more scalable than returning hundreds of thousands of records in a single response.

Architecture determines efficiency long before infrastructure becomes a problem.

Observability as a Platform Requirement

Visibility is not optional.

Without observability, systems become difficult to understand and improve.

Three pillars are essential:

Logs
Metrics
Traces

Together they answer:

What happened?
How often?
Where did it happen?
Why did it happen?

An observable platform is easier to operate, maintain, and evolve.

Common Architectural Mistakes

Breaking Existing Contracts

Changing APIs without versioning creates instability.

Business Logic Inside Controllers

Bad:

Controller = Business Logic

Better:

Controller
    │
    ▼
Service Layer
    │
    ▼
Repository

Returning Excessive Data

Large responses increase:

Memory consumption
Query costs
Response times

Use pagination.

Missing Rate Limiting

Without protection, systems become vulnerable to:

Abuse
Traffic spikes
Resource exhaustion
Cost increases

Rate limiting should be considered a foundational capability.

Architecture Evolution Roadmap

Most successful platforms evolve gradually.

Simple CRUD APIs
         │
         ▼
Authentication
         │
         ▼
Authorization
         │
         ▼
Caching
         │
         ▼
Background Jobs
         │
         ▼
API Gateway
         │
         ▼
Event-Driven Architecture

The goal is not maximum complexity.

The goal is appropriate complexity.

Systems should evolve in response to real requirements rather than assumptions.

Conclusion

API architecture is not about endpoints.

It is about designing how capabilities are exposed, consumed, secured, reused, and evolved.

A well-designed API architecture creates leverage.

It allows multiple products, integrations, automations, and future initiatives to operate on a shared foundation.

The result is:

Faster development
Better scalability
Easier integrations
Lower operational costs
Stronger security
Improved maintainability
Better developer experience

The most valuable APIs are not simply interfaces.

They are the contracts that define how an entire software platform operates, grows, and adapts over time.

That is why API architecture is not merely a technical concern.

It is a fundamental platform design decision with long-term business consequences.