SaaS platforms

SaaS Development From First MVP to Paying Customers

SaaS development for founders and established businesses productising something they already do. We build the multi-tenant platform, the billing, the roles and the dashboards — and we build the smallest version that can charge money first, because that is the version that tells you whether the rest is worth building.

Scope Your MVPSee our work

Most failed SaaS builds were too big on day one

The pattern is consistent. Nine months of development, a feature list assembled from every conversation the founder had, a launch, and then the discovery that customers wanted three of the twenty-two features and would have paid for those alone in month three.

The money is not really lost on the extra features. It is lost on the six months of feedback that never happened, because nothing was in front of a user long enough to generate any.

So we build the paid path first: sign up, do the one thing the product exists to do, get billed for it. Everything else is a decision you make later with real usage data instead of guesses.

What we build

Multi-tenant architecture

Workspaces or organisations with properly isolated data, so one customer can never see another's records. Designed at the start — retrofitting tenancy into a single-tenant schema is close to a rewrite.

Subscription billing

Stripe or Paddle integration with plans, trials, upgrades, downgrades, proration, failed-payment retries and dunning. Plus the unglamorous parts: invoices, tax handling and what happens when a card expires.

Accounts, roles and permissions

Team invitations, role-based access, SSO where it is needed, audit logs, and an admin console you can use to support customers without querying the database by hand.

Dashboards and reporting

The screens customers actually log in for, plus the internal metrics you need — activations, churn, usage per plan — available without exporting to a spreadsheet.

APIs and webhooks

A documented public API with keys and rate limiting, and outbound webhooks, so customers can connect your product to their stack. Often the difference between a tool and a platform.

Cloud deployment and CI

Automated deploys, staging and production environments, database backups, error tracking and uptime monitoring. Set up once so shipping an update is not an event.

How we work

  1. Define the MVP

    We work out the shortest path from sign-up to payment and cut everything not on it. This conversation removes more scope than any other part of the project.

  2. Fixed quote

    A written scope and a fixed price for the MVP. Later phases are quoted separately once you have real users, rather than guessed at now.

  3. Build in two-week cycles

    A deployed staging environment from week one, updated every cycle. You are using the product while it is being built, not reviewing a specification.

  4. Launch and hand over

    Production deploy in your cloud account, monitoring and backups configured, the repository and documentation transferred to you.

What we build on

Boring, well-documented technology on purpose. You will hire other developers eventually, and the stack should not narrow that pool. If your product is really a mobile-first one, start at mobile app development; if it is an internal tool rather than a product you sell, see web development.

Front end
React, Next.js, TypeScript, Tailwind CSS
Back end
Laravel, Node.js
Data
PostgreSQL, MySQL, Redis for queues and caching
Billing
Stripe, Paddle
Infrastructure
AWS, Vercel, Docker, GitHub Actions

Platforms we have built

We build our own SaaS products, not only client work. It is a different discipline. You own every architectural decision and you live with all of them, including the ones that turn out wrong.

One of ours is built and running internally.

CROSignal

AI-powered conversion audits for ecommerce

Submit any Shopify or WooCommerce page and get a scored report in about sixty seconds. It grades six categories — conversion, trust and social proof, copywriting, mobile UX, page speed and SEO — then returns the three highest-impact fixes plus eight to twelve detailed findings, each with severity, supporting evidence and a specific recommendation.

What it took to build

  • Queue-based architecture. Live page analysis takes longer than a serverless function is allowed to run, so audits are queued and processed by a scheduled worker rather than blocking a request.

  • A scraping layer with a fallback. Playwright renders JavaScript-heavy stores; a lightweight HTML parser handles the rest without the overhead of a browser.

  • An AI pipeline that assumes failure. Model output is validated against a schema, malformed responses are repaired, and a deterministic fallback means a failed model call never produces a broken report.

  • Security on untrusted input. The product accepts user-supplied URLs, which is a textbook SSRF vector. Private IP ranges, localhost and internal hostnames are blocked, with DNS resolved before any request is made.

  • Commercial infrastructure. Subscription billing with tiered feature access, PDF export gated by plan, historical score tracking, transactional email, and per-client rate limiting with hashed rather than stored IP addresses.

Stack
Next.js · TypeScript · Supabase Postgres · OpenAI · Playwright · Stripe
Status
Built. Pre-launch.

It is not publicly launched yet. We are telling you what we built rather than what we sold, because the engineering is the relevant part when you are choosing who builds yours.

How we scope and price a platform

A focused MVP — authentication, one core workflow, subscription billing and a basic dashboard — is a different engagement from a full platform with several user roles, a public API, integrations and an admin console. Both are quoted the same way, against a written scope, but the second is a programme and the first is a project, and it is worth being honest with yourself about which one you are buying.

We also take narrower work: a prototype for investor or customer conversations, adding billing and tenancy to something you have already built, or one defined phase on an existing platform. If you do not need the whole thing yet, we would rather scope the part you do need.

We quote the MVP as a fixed scope and price later phases separately, once usage data exists to justify them — pricing phase three today means guessing at what your first hundred users will ask for. Cloud hosting and Stripe fees go to those providers directly and are not marked up.

Tell us what the platform has to do and who its tenants are, and you will get a scoped MVP with a fixed price on it, plus an honest view of what we would leave until later.

The parts founders do not budget for

Most SaaS quotes cover the features you can describe. The overruns come from the ones you cannot yet.

  • Tenant isolation

    Every query has to be scoped to the right account, enforced at the database level rather than trusted to application code. Get it wrong and one customer sees another's data. Retrofitting it means rewriting your data layer.

  • Billing that survives contact with reality

    Subscriptions are simple until someone upgrades mid-cycle, a card fails, a webhook arrives twice, or a refund needs prorating. Handling those states is most of the work.

  • Jobs that outlive the request

    Anything over sixty seconds cannot run in a serverless function. You need a queue and a worker, and that is an architectural decision, not a detail.

  • Rate limiting and abuse

    The moment you have a public endpoint, someone will hammer it. Per-account limits need to exist before launch, not after the first incident.

  • Fetching user-supplied URLs safely

    If your product accepts a URL, you have an SSRF vulnerability until you explicitly close it.

  • Email compliance

    Transactional versus marketing, unsubscribe handling, bounce and complaint processing. Skip it and your sending domain is burned in a month.

We have shipped all of this. It is why our estimates sometimes look higher than the quote that ignored them, and why they hold.

Why work with us

  • We cut scope before we quote it

    The first serious conversation is about what to leave out. It is the cheapest part of the project and it saves the most money.

  • Billing is treated as a core feature

    Trials, proration, failed payments and dunning are where most SaaS products leak revenue quietly. They are in the MVP scope, not deferred to a later phase.

  • It runs in your accounts

    Your AWS or Vercel account, your Stripe account, your domain, your repository. Nothing sits behind our credentials, so leaving us costs you nothing but a handover call.

  • We quote the MVP, not the roadmap

    One fixed price for the scope we agreed, with later phases priced when there is usage data to justify them rather than guessed at now.

Frequently asked questions

How long does a SaaS MVP take?
Ten to fourteen weeks from kickoff for a properly scoped MVP: authentication, multi-tenancy, one core workflow, subscription billing and a dashboard. Anything promised in four weeks is either a prototype without billing or a template with your logo on it. Larger platforms with multiple roles and integrations run five to eight months.
What should be in the MVP and what can wait?
In: sign-up, the single workflow the product exists to perform, and payment. Nearly everything else can wait, including team management, integrations, a public API, granular permissions and most reporting. If a feature does not sit between a new user and their first payment, it is a phase-two decision.
Do we own the code and the infrastructure?
Yes. The repository is yours, and the platform runs in your cloud and Stripe accounts from day one. We do not host your product on our infrastructure or hold your billing credentials.
Can it handle growth?
It is built to grow without a rewrite: proper tenancy, indexed queries, background jobs for slow work, and stateless application servers so you can add capacity. We do not over-engineer for a scale you do not have yet — the first version does not need Kubernetes, and adding it later is straightforward when the architecture is sound.
Will you work with our in-house developers?
Yes. Shared repository, code review both ways, and agreed conventions from the start. We can also build the foundation and hand it to your team to continue, which is a common arrangement.
What happens after launch?
Maintenance plans cover monitoring, dependency updates, backups and fixes, priced monthly against the platform we shipped. Feature work after launch is quoted per phase. Both are optional — plenty of clients take the handover and continue in-house.
We have an idea but no technical co-founder. Is that a problem?
No, that is a common starting point. What we do need is clarity on who the customer is and what they will pay for. If that is still vague, the honest advice is usually to sell the service manually to a handful of customers first, and build the software once you know exactly which part to automate.

Other services

Browse everything we build on the software development services hub, or see recent builds in our portfolio.

AI Automation Services

Chatbots, AI agents and workflow automation that remove repetitive manual work. Built on OpenAI, Claude, n8n and your existing tools.

WordPress Plugin Development Services

Custom WordPress plugins, WooCommerce extensions, REST API integrations and plugin licensing systems for businesses that have outgrown off-the-shelf.

Web Development Services

Fast, SEO-ready websites and web applications in Next.js, React and WordPress. Headless CMS, e-commerce, progressive web apps and API integration.

Start with the version that can charge money

Tell us what the product does and who pays for it. We will tell you what belongs in the first version, roughly how long it takes, and what it costs. No charge for that conversation.

Scope Your MVP