Skip to content
Brain Matrix
Book a call

Problem 03 — Building a product

You have a product idea and need it engineered properly

Most first versions do not die of missing features. They die of architecture — a data model that cannot take a second customer type, or a tenancy decision made implicitly in week one. We build products that can survive their own success.

Symptoms we hear

  • A prototype that cannot take real customers
  • No clear path from demo to paying users
  • Engineering capacity gone, roadmap stalled
  • Every new customer needs bespoke work

The problem

The problem, stated plainly

There is a specific failure mode in early product engineering that is easy to miss while it is happening. The prototype works, the demo lands, the first customers sign — and then the second kind of customer arrives, and everything that was implicit in the data model becomes an explicit, expensive problem.

The decisions that cause this are not glamorous. Tenancy, identity, the shape of the core entity, where permissions live, and how billing relates to usage. They are cheap to decide in week one and very expensive to change in month nine, which is precisely when they usually surface.

  • A prototype that cannot safely take real customers
  • No clear path from demo to paying users
  • Every new customer needs bespoke work
  • Engineering capacity has gone and the roadmap has stalled
  • Adding a second customer type means rewriting the data model
  • Nobody can say what the product does not do

Root cause

Why this happens

Understanding why a problem exists is what separates a solution from a workaround.

  1. 01

    Speed was correctly prioritised, and never revisited

    Shipping fast to test an idea is right. The failure is not the shortcut; it is that nobody scheduled the moment to look at it again, and shortcuts do not raise their own hands.

  2. 02

    Tenancy was decided implicitly

    Every product makes a tenancy decision. Products that make it deliberately can change it later; products that make it by accident discover it during a migration under load, with customers watching.

  3. 03

    The first customer shaped the product

    Building exactly what the first customer asks for is how you get one very satisfied customer and a product that is hard to sell twice. The skill is separating the general requirement from the specific request.

  4. 04

    Nobody owned the boring parts

    Billing edge cases, admin tooling, onboarding and support surfaces are unexciting and load-bearing. They are what turns working software into a business, and they are what teams defer until they become urgent.

Possible solutions

The options actually available

How you build the first version should follow what you are actually trying to learn — and different goals justify genuinely different engineering.

Prototype to test demand

When it fits

The question is whether anyone wants it. Build the smallest thing that produces a real signal.

What to watch

Do not let it become the product by default. Decide in advance what would justify starting properly, and what would justify stopping.

A production first version

When it fits

Demand is established and the next question is whether it works at real scale with real money.

What to watch

Scope. The temptation is to build the version you eventually want rather than the version that can be sold next quarter.

Rebuild the foundations under a working product

When it fits

Traction exists but the architecture is now the constraint on selling to bigger customers.

What to watch

Do it in slices behind the running product. Stopping to rewrite is how companies lose the traction that justified the rewrite.

Senior capacity alongside your team

When it fits

You have engineers but need architecture, a hard subsystem, or an extra senior pair of hands on a deadline.

What to watch

Boundaries. This works when ownership of specific areas is clear, and it goes badly when it is not.

Not building it yet

When it fits

The idea has not been tested with anyone who would pay, or it can be run manually first to learn the process.

What to watch

Running it manually first is undervalued. It is the cheapest way to discover what the software should actually do.

Our approach

How we approach it

Product engineering is a sequence of decisions about what to make expensive later. We try to make the right things expensive.

  1. 01

    Settle tenancy, identity and the core entity first

    These three decide what version two can be. A week spent here — with the awkward second customer type explicitly in mind — is worth more than any other week in the project.

  2. 02

    Define what version one is not

    Written down, agreed and visible. A scope boundary that exists only in someone's head will not survive contact with an interesting idea on a Thursday afternoon.

  3. 03

    Build the commercial surfaces early

    Billing, plan limits, onboarding and admin tooling. These are what make it a business rather than a demo, and retrofitting them is consistently worse than building them in.

  4. 04

    Ship to real users in weeks

    A narrow release used by real customers beats a broad release used by nobody. It also surfaces the assumptions that would otherwise be discovered at scale.

  5. 05

    Instrument the product, not just the servers

    Activation, retention, feature usage and where people give up. Without this you are choosing what to build next from opinion, which gets more expensive as the team grows.

Technical capability

What we actually build with

Listed so a technical evaluator can judge us on specifics rather than adjectives.

Product architecture

  • Multi-tenant data models
  • Identity, roles and permissions
  • Subscription and usage-based billing
  • Plan limits, trials and gating
  • Admin and support tooling

Application engineering

  • Next.js, TypeScript and modern React
  • API design — REST and GraphQL
  • Background jobs and queues
  • Real-time and collaborative features
  • Design systems and component libraries

AI product features

  • LLM features with evaluation harnesses
  • Retrieval with tenant isolation
  • Usage metering and cost control
  • Guardrails and human review flows

Scale & operations

  • Performance under realistic load
  • Observability and error tracking
  • Infrastructure as code
  • Security review and hardening
  • Enterprise readiness — SSO, audit logs

Qualification

Whether this is for you

We would rather lose a project than take one that should not exist.

This works well when

  • A founder or product owner who can make decisions quickly
  • A real user group available for early releases
  • Willingness to scope version one narrowly
  • Funding for a phase, with the option to continue

We are the wrong choice when

  • A fixed feature list that cannot change as you learn
  • No access to prospective users
  • An expectation of a fixed price for an undefined product
  • A launch date that assumes nothing will be learned on the way

Relevant work

What this looks like in practice

B2B services2026Anonymised

A prospecting engine where the model writes the query, never the data

Output looked excellent and could not be trusted, which is worse than output that looks poor.

The first version used a language model to generate leads, which meant it sometimes invented them. We rebuilt it so the model produces a search specification and verified sources produce the rows — multi-tenant, and auditable back to source.

  • TypeScript
  • Node
  • LLM integration
  • Third-party data APIs
  • Workflow orchestration

Brain Matrix Labs — free tool

SaaS Complexity Estimator

See the complexity and a sensible phase breakdown for what you are planning.

Open the tool

Questions

What clients ask us

How much does it cost to build a SaaS product?

Honestly: it depends on things a form cannot capture, and any figure quoted before understanding your data, users and integration surface is a guess. The same feature list can differ by an order of magnitude. Our complexity estimator gives you a complexity score and a phase breakdown rather than a number, which is more useful early — and once we understand the scope, we price a defined phase rather than an open-ended project.

Can you build an MVP in six weeks?

Sometimes, and it depends entirely on what MVP means in your case. A narrow product with a clear first user group can reach production in that time. A multi-tenant product with billing, roles and integrations cannot, and we would rather say so than agree and then explain later.

What if we already have a codebase?

That is common. We start by reading it and telling you honestly what it is: sound and extendable, sound but structurally limited, or genuinely better to replace in parts. Wholesale rewrites are rarely the right recommendation, and we do not open with one.

Will you work with our existing engineers?

Yes. A frequent arrangement is that we own the architecture and the harder subsystems while your team builds alongside, which transfers knowledge continuously rather than in a handover at the end.

Do we own the product outright?

Yes — code, infrastructure, accounts and documentation. Everything is set up so that you can bring it in-house or move it elsewhere without our involvement.

How do you handle a pivot mid-build?

Phases exist precisely so this is possible. Each phase ends with something usable and a genuine decision point. Pivots are expensive when a team is nine months into a big-bang build; they are ordinary when the work is sliced properly.

Further reading

On this topic

SaaS & Product Engineering4 min read

How much does it cost to build a SaaS product? An honest answer

Every published figure for building a SaaS product is either a marketing number or a range so wide it means nothing. Here is what actually drives the cost, and how to get an estimate you can rely on.

Solutions

Other problems we solve

Next step

Let's talk about what's holding your business back.

A 45-minute conversation with a senior engineer. We will look at your situation, say what we would do, and tell you if the answer is not software. No pitch deck, no pressure.

Book a strategy callExplore the Labs tools