Atmora Tech

Engineering

Twelve weeks to
an answer you can act on

An MVP exists to answer one question you cannot answer with a deck or a survey. We agree that question in week one, build only what tests it, and hand over a system that can be extended instead of a prototype that has to be replaced.

Overview

One question answered in twelve weeks, in code you will not be forced to throw away.

The failure mode in MVP work is not building badly, it is building too much. Every feature added before the first real user is a bet placed without information, and the ones that turn out wrong are expensive twice: once to build, once to remove. We keep a written scope boundary from day one and treat pressure to cross it as a sign the question was never agreed.

Twelve weeks is our usual shape: two weeks of definition and prototyping, eight of build in fortnightly increments, two of hardening and launch. What ships is deliberately narrow, often one user role, one payment path and one integration, but it is production-grade underneath, with real authentication, migrations, backups, error tracking and a deployment pipeline.

We do not use throwaway stacks to save a fortnight. The MVP runs on the same technology we would pick at a hundred thousand users, because the difference in build cost at this size is a few days, and the cost of rewriting the foundations eighteen months later is a full quarter of your engineering capacity.

68 days
Fastest launch to date: the Orbit Supply carrier booking portal
9 features
Cut from the original brief during week two, before any code was written
11.5 weeks
Median kickoff to first external user across our last nine MVP engagements

Capabilities

What this covers

Six areas we staff properly. If your problem sits outside them, the honest note at the foot of this page says so.

  • Question framing and cut list

    A single learning objective written down, with an explicit list of what is being excluded and the reason for each exclusion, so scope arguments in week seven are settled by a document rather than seniority.

  • Prototype before code

    A clickable Figma prototype of the primary journey tested with five to eight target users, because finding out the flow is wrong costs two days at this stage and three weeks after the build starts.

  • Narrow production build

    One role, one path through the product, built properly: real authentication, database migrations, background jobs and payment handling that reconciles rather than a demo integration in test mode.

  • Instrumentation for the question

    Analytics events defined against the learning objective before launch, so you get an answer from the first hundred users instead of a dashboard of page views nobody can act on.

  • Launch infrastructure

    Infrastructure as code, a CI pipeline with automated rollback, daily backups tested by restoring them at least once, and error tracking wired to somewhere a human will actually see it.

  • Iteration or clean handover

    Either a fortnightly iteration cadence continuing after launch, or a documented handover to your first in-house hires including a prioritised backlog and the known shortcuts we deliberately took.

Deliverables

What you get

  • Scope boundary document listing what is excluded from version one and why
  • Figma prototype of the primary journey, tested with five to eight target users
  • Production application with authentication, payments and one external integration
  • Analytics instrumented against the specific question the MVP was built to answer
  • Infrastructure as code, CI/CD pipeline and a tested restore-from-backup procedure
  • Two-week post-launch support window with a prioritised, costed backlog

Stack

What we build it with

  • Next.js 16
  • TypeScript
  • PostgreSQL
  • Prisma
  • Stripe
  • Clerk
  • Tailwind CSS
  • Resend
  • PostHog
  • Sentry
  • Terraform
  • Playwright

Process

How the engagement runs

Two-week increments against a written definition of done. You can stop at any increment boundary and keep everything built so far.

  1. Week one: the question

    Two days of workshops to reduce the idea to one testable question, the audience it must be tested with, and the evidence that would count as an answer.

  2. Week two: prototype and cut

    A clickable prototype tested with real target users, followed by a cut list. Typically a third of the original brief does not survive this conversation.

  3. Weeks three to ten: build

    Four fortnightly increments, each ending with working software in staging. You use it every second Thursday and the backlog is re-ordered based on that.

  4. Weeks eleven and twelve: harden

    Security review, load testing at ten times expected launch traffic, restore rehearsal, and the accessibility and legal pages that quietly block go-live.

  5. After launch: read the data

    Two weeks of support and a structured review of what the instrumentation says, ending with a recommendation to continue, pivot or stop.

When this is the wrong engagement

If you already have paying customers and a validated model, this is the wrong engagement, because you need a product team working against a roadmap rather than a twelve-week experiment with a hard scope boundary.

FAQ

Questions we get asked

What does a twelve-week MVP cost?

It is priced per phase against a fixed scope, with a team of four: a tech lead, two engineers and a product designer, plus part-time QA in the final phase. The definition phase is quoted separately and small, so you can stop after two weeks if the scoping shows the idea is not ready.

What if we need more than one user role?

Then it is probably not an MVP, it is a version one, and it needs sixteen to twenty weeks. We will say so rather than compress the plan. Marketplaces are the honest exception, since two sides are structural, and we plan a longer definition phase for those.

Do you build with no-code tools to go faster?

Occasionally for internal admin screens or a landing page, never for the core product. No-code saves two or three weeks up front and costs a full rebuild the moment you need custom permissions, an unusual integration or performance work under load.

Who owns the code and the accounts?

You do, from the first commit. The repository, cloud accounts, domain and third-party services are created in your name and we are added as collaborators. On completion we remove our access. There is no hosting lock-in and no proprietary framework of ours in the stack.

Related

More in Engineering

Start a project

Tell us what is
breaking.

We reply within one working day, and the first call is with an engineer who would actually work on it — not an account manager. If we are not the right studio for the problem, we will say so on that call.

Start a project