How a Build Actually Runs, Week by Week
Four steps, no mystery. This page is the long version: what we ask, what you sign off, what happens in sprint one versus sprint four, who is responsible for what, and what you are holding the day the engagement ends.
A Process Is Only Useful If You Can Hold Us To It
Most projects do not fail because someone wrote bad code. They fail because nobody agreed what finished meant, changes were absorbed silently until the budget ran out, or three months went by with nothing anyone could open. Every step below exists to remove one of those failure modes: a written scope before pricing, a signed-off prototype before production code, a usable build every two weeks, and a change process with numbers attached.
Nothing here is unusual. It is simply written down, which is rarer than it should be.
Compare engagement modelsFrom First Call to Post-Launch Support
Timings below describe a typical first version. Larger products stretch the middle, not the shape.
01 — Free Estimate Call
A 30 to 45 minute conversation, no charge and no obligation. We are not selling on this call; we are trying to work out whether the thing you want built is buildable for the money you have.
What we ask you
- Who uses this, and what are they doing right now instead?
- What has to be true on launch day for this to count as a success?
- Which platforms genuinely matter first, and which are wishes?
- What systems does it have to talk to, and do you control them?
- What is the budget and the date, and which of the two is fixed?
What you receive afterwards
Within two business days: a written scope outline listing the features we heard, a budget range with the assumptions it rests on, an indicative timeline in weeks, and an explicit list of what we would leave out of version one and why. If we think you should not build this yet, that is in the document too. You can take that scope to another firm; it is yours either way.
02 — Discovery, Design and a Clickable Prototype
Usually one to three weeks. Discovery turns the scope outline into decisions: user roles and what each can see, the data model, the third-party services, the rules that are not obvious from the screens. Design turns those decisions into something you can look at.
You get the full screen set as designs and a clickable prototype — a linked mock-up you can open on your own phone or laptop and tap through as though it were real. Put it in front of three people who resemble your users before you approve it. Almost every project changes something at this point, and this is the only stage where changing it is nearly free.
What sign-off actually means
Approving the prototype fixes the screen inventory, the navigation and the user roles for version one. That is what makes a fixed price possible: we are pricing a defined set of screens and behaviours, not an idea. After sign-off, changes inside a screen stay cheap; adding a screen, a role or an integration becomes a change request with its own estimate. Nothing is locked forever — it is locked until you decide it is worth paying to move.
03 — Sprint-Based Build
Production work runs in two-week sprints. Each sprint has a written goal agreed at the start and ends with a build you can install and use yourself.
Sprint 1 versus sprint 4
Sprint one is deliberately unglamorous: project setup, repositories and environments in your accounts, the database schema, authentication, deployment pipeline and one thin end-to-end slice so we prove the whole stack works together early. It often looks like the least visible progress of the project and it is the sprint that prevents most disasters.
By sprint four the foundations are behind us and the app grows fast. Features land in the order you ranked them, so if something has to be cut later, what gets cut is what you already said mattered least. Integrations with anyone else's system are scheduled early rather than late, because that is where the surprises live.
Demo cadence and reporting
- A working demo build every two weeks, installable on your own device
- A written update at the end of every working day: done, blocked, next
- A shared board you can open at any time without asking anyone
- A sprint review call scheduled in your morning, US Eastern time
How QA and testing work
Testing is not a phase at the end. Every feature is checked against its acceptance criteria before the sprint closes, on real devices rather than only a simulator. Automated tests cover the logic that would be expensive to get wrong — payments, permissions, calculations, anything touching money or personal data. You get a test account and are encouraged to break things; bugs you find go on the same board we use, with a severity and an owner, and critical defects are fixed inside the current sprint rather than queued.
How change requests are handled
Ask for anything at any time. Small adjustments within an existing screen are absorbed. Anything larger comes back the same day or the next as a short note: what it affects, the estimate in hours and dollars, and whether it moves the launch date. You approve or decline in writing, and only then does it enter a sprint. No change is ever done quietly and invoiced later.
04 — Launch
Release is its own piece of work, not an afternoon. For mobile we prepare the store listings, screenshots, privacy declarations and data-use disclosures, submit under your developer account, and handle review feedback until the app is approved. First-time submissions are commonly rejected for reasons that have nothing to do with code, such as missing account deletion or an unclear privacy answer; we expect that and build review time into the plan.
Release checklist
- Production environment separated from staging, with backups switched on
- Error tracking, uptime monitoring and basic analytics wired up before launch
- Live payment keys tested with a real transaction, not a sandbox one
- Privacy policy, terms and any required disclosures published and linked
- A documented rollback path if the first release goes badly
- Handover documentation and credentials confirmed in your accounts
The post-launch support window
Every build includes a support window after release — typically 30 days, agreed in the contract — during which defects in what we delivered are fixed at no charge. That window is for bugs, not new features: if real users reveal something you want built, it is quoted as new work. Most clients move onto a maintenance retainer when the window ends, because the month after launch is when operating systems update and real usage finds the corners.
See maintenance and supportWhat We Need From You
Projects rarely slip because of engineering. They slip waiting for an answer, an account or a decision.
Access, early
Accounts and credentials for anything we must integrate with: your payment processor, CRM, email provider, existing database, and the Apple and Google developer accounts. We create what does not exist yet in your name, but we cannot invent access to systems a third party controls. Chasing a vendor for API keys in week six is the single most common cause of delay.
Decisions inside two business days
One named person with authority to approve designs, scope changes and release dates. We ask for approvals to come back within two business days; longer than that and the sprint plan has to be re-cut, because engineers cannot sit idle waiting for a choice about a screen. Design by committee is fine as long as the committee meets before the deadline.
Honest feedback on demo builds
Install every demo build and actually use it. Twenty minutes of real clicking beats an hour of discussion. Tell us when something feels wrong even if you cannot say why — that instinct is usually right and it is far cheaper to act on in sprint three than in the week before launch. Silence reads as approval, and silence is expensive.
How We Stay in Touch, Stated Plainly
Our delivery team is not based in the United States. Rather than pretend otherwise, here is exactly what we commit to.
End-of-day written update
Every working day, in your project channel: what was finished, what is blocked and what happens tomorrow. It is a record you can scroll back through, not a meeting.
Calls in your morning
Scheduled calls are booked in the client's morning, US Eastern time, so you are speaking to us at the start of your day rather than at midnight.
Reply within one business day
Anything you raise gets a substantive answer inside one business day. If the answer needs investigation, you get told that, plus when to expect the real reply.
Demo build every two weeks
A real installable build at the close of each sprint. Progress you can hold is harder to fake than a status report, which is rather the point.
We do not claim live US-hours coverage or a daily standup you attend. The commitments above are the ones we can keep every week, which makes them worth more than the ones we cannot.
Who Does What
Ambiguity here is where most client and agency relationships go wrong. Read this before you sign anything, with us or anyone else.
Delivery and engineering
- Architecture, database design and technology choices
- UI and UX design, prototype and build
- QA on real devices and automated tests where they earn their keep
- Deployment pipeline, environments and monitoring setup
- Store submission and handling review feedback
- Technical documentation and handover
Decisions and access
- Approve designs, scope changes and the release date
- Provide credentials for systems you or a vendor control
- Own the Apple and Google developer accounts and pay their fees
- Supply final copy, legal text, logos and brand assets
- Test each demo build and report what feels wrong
- Decide the business rules only you can decide
Agreed in the contract
- Writing in-app copy when you would rather we drafted it
- Migrating data out of an old system into the new one
- Managing cloud infrastructure on your behalf after launch
- Compliance work such as HIPAA or SOC 2 readiness support
- Training your staff on an internal tool we built
Things we will not pretend to do
- Marketing, app store optimisation or paid user acquisition
- Legal advice, or drafting your privacy policy and terms
- Paying third-party licence, API or cloud hosting costs
- Guaranteeing app store approval, which is never anyone's to promise
- Live US-hours staffing or a daily standup you have to attend
You Should Be Able to Leave Without Asking Us
Whether we part after one MVP or three years of work, nothing about the handover should be a negotiation.
What stays with you
- Source code, in repositories created in your organisation on day one — there is no transfer event because it was never ours to hold.
- Cloud accounts, domains, app store listings and any third-party service accounts, all registered to you and paid by you.
- Design files, the clickable prototype and the exported assets.
- Environment and deployment documentation: how to build it, where it runs, what each variable does, how to restore a backup.
- Intellectual property, transferring in full on final payment as set out in the contract.
How the handover runs
- A written architecture summary a new engineer can read in an afternoon and act on the next morning.
- A walkthrough call with whoever takes over, ours or yours, recorded if you want it.
- Any credentials we held are rotated and removed from our side, and we tell you when that is done.
- An honest list of known issues and shortcuts, including the ones that are inconvenient for us to admit.
- If you come back in a year, we can pick it up again — but you are never dependent on that being true.
Questions About How We Work
How long does the whole process take?
A focused first version is usually 8 to 16 weeks from kickoff to store submission, split roughly into one to two weeks of discovery and design, four to six two-week build sprints, and one to two weeks of release work. Products with several user roles, heavy integrations or compliance requirements run longer. You get a week-by-week plan before any production code is written, and that plan is updated in writing the moment reality moves away from it.
What happens if I want to change something in the middle of a build?
Small changes inside a screen we have already agreed are absorbed as normal work. Anything that adds a screen, a user role, an integration or a new business rule is written up as a change request with its own estimate in hours and dollars, and nothing starts until you approve it in writing. Quietly absorbing changes is exactly how fixed-price projects turn into arguments at the end.
How often will I see working software?
At the end of every two-week sprint you get a build you can install and use yourself, not a screenshot or a recorded video. Between demos you get a written update at the close of each working day covering what moved, what is blocked and what is next. If something is going wrong you hear about it in that daily update rather than at the demo two weeks later.
When are you available for calls?
Our delivery team is not based in the United States, so we will not pretend to sit at a desk through your entire working day. What we commit to is a written update at the end of every working day, calls scheduled in your morning US Eastern time, a reply to anything you raise within one business day, and a working demo build every two weeks. Most clients find the written record more useful than a daily meeting they have to attend.
What do I get at the end of the project?
Everything. Source code in repositories that were already in your name, cloud and app store accounts you own, environment and deployment documentation, design files, test credentials and a written handover explaining how the system is put together and what to watch for. Intellectual property transfers on final payment, and there is nothing technical for us to hold back.
Start With the Estimate Call
Half an hour, no charge, and you leave with a written scope and budget range whether or not you hire us.