You have an idea, and no way to find out whether anyone wants it.

From product idea to a first real release

The hardest part of a first version is deciding what not to build. We scope deliberately narrow, ship something real, and let what users actually do decide the second release.

Problems we solve

Where this usually starts.

An idea with no shape

A clear sense of the problem and no agreed definition of version one.

Scope with no floor

A feature list that keeps growing and a launch date that keeps moving.

Nothing to show

A need to demonstrate something working to customers, partners or investors.

A prototype at its limit

Something built quickly to prove the idea that now needs to hold real users.

What we build

Typical solutions.

  • Minimum viable products
  • Multi-tenant SaaS platforms
  • Subscription and billing integration
  • User accounts and permissions
  • Admin and support tooling
  • Analytics and usage tracking

What is included

Every engagement covers.

  • Discovery and requirements
  • UX and interface design
  • Architecture and data modelling
  • Development and code review
  • API design and integration
  • Testing and QA
  • Deployment and production setup
  • Documentation
  • Handover of code and accounts

Technology we commonly use

  • React
  • TypeScript
  • Node.js
  • PostgreSQL
  • Stripe
  • Cloudflare

Chosen per project against the requirement — not a fixed stack, and not a list of everything we have ever touched.

Questions

The things people actually ask.

What belongs in version one?

The smallest thing that lets a real user complete the core task end to end. Not a prototype, and not a feature list — a narrow product that genuinely works. Everything else waits for evidence.

Do you take equity instead of payment?

No. We work on a paid basis, which keeps the relationship straightforward and means our incentive is to build what you need rather than to protect a stake.

What if we need to change direction?

Expected, and the reason for shipping narrow early. Scope is agreed per phase rather than for an imagined finished product, so changing direction means scoping the next phase differently, not renegotiating everything.

Can you keep developing it after launch?

Yes, if that suits you. Ongoing development is available, and equally you can take it in-house — the ownership and documentation position is designed to make that a real option rather than a theoretical one.

Get in touch

Tell us what you’re trying to build.

You don’t need a finished specification. Describe the problem, the existing process or the product idea, and we’ll take it from there.