How we run delivery, from first call to support

Every product we build goes through six steps: discovery, design, build, QA, launch and support. None of those names will surprise you. What matters to a founder is what you hold at the end of each step, who you talk to along the way, and what happens when the plan changes. This note covers each of those.

One team from first call to support

One rule shapes all six steps. The people who scope your product also design, build and support it. There is no handover from the people who sold the project to a separate delivery team, and no separate support desk that first sees your product after launch.

You talk to the engineers building your product, and one project manager keeps the plan. That gives you two kinds of contact. The project manager can tell you where the work stands and what comes next. The engineers can tell you how something works and what it would take to change it.

The team that starts it stays to support it.

1. Discovery

Discovery turns your goals, your users and your constraints into a roadmap. It starts after the first call and an NDA. Discovery workshops come first, and what else happens depends on the product. For design work, we add user interviews, surveys and a look at the analytics you already have. For an ERP, we map how your departments work today, so the modules that matter most get built first.

Our project manager and tech lead then write up three documents:

• The BRD sets out your business goals, the scope and the measures of success.
• The SRS lists the functional and non-functional requirements, with the user stories.
• The SDS covers the architecture, the data model, the integrations and the tech stack.

An estimate and a proposal follow from those. Your decision-maker signs off all three documents, and the sprints start after sign-off. Every product is different, so the estimate comes out of discovery.

At the end of discovery you have the three signed documents, an estimate and a proposal.

Four ways to engage

All four engagement models are open to you:

• Fixed price, for a well-defined scope after discovery.
• Time and materials, for a product that keeps changing. Invoices are itemized with no hidden fees.
• A dedicated team that works only on your product, on a monthly basis.
• Paid discovery first. Discovery, the BRD and the SRS run as a small paid phase before you commit to any build.

For an early-stage startup, the roadmap can start with a lean MVP, and the engagement model can change as the company grows.

2. Design

Design turns that research and your brand into interfaces and flows. We settle the structure first with wireframes, then move to high-fidelity screens. Interactive prototypes go in front of real users before development starts, because changes are still cheap at that point.

If you have brand guidelines, we design within them. If you don't have any yet, we can create them.

At the end of design you have tested flows, high-fidelity screens, and developer-ready specs for every component and state. The designers keep working with the engineers through the build, so a question about a screen goes to the person who designed it.

3. Build

We build in sprints, and you get working software to try every week. Weekly demos and reviews let you see progress and change course early, while a change is still small. Scope, time and budget come up in those reviews, so when requirements change, you see what the change means for all three before you agree to it.

The most valuable parts come first. On Neptune EHS, a product we built from the first commit, the backend came first, then the incident module, then the dashboard that summarises it. The AI features came last, after the data they read.

On mobile projects, you test real builds on your own phone early in the project, not only mockups.

At the end of each week you have a demo, a build you can try yourself, and a plan the project manager keeps current.

4. QA

Every release goes through manual and automated tests before it ships. The automated tests run in the release pipeline, so no release skips them.

What the rest of QA covers depends on the product. A mobile app gets its permissions, privacy labels and store assets checked before submission. A game gets a test matrix across devices and inputs. An AR app gets profiled for frame time, heat and battery, and tested on devices across OS versions and chips.

At the end of QA you have a release that passed both kinds of test.

5. Launch

We treat launch as the first of many releases. We set up the CI/CD pipelines and the cloud environment, so every release after the first goes out the same way. For a web app, that means releases to AWS, Vercel or containers, with preview environments where you can check a feature before it goes live. For a mobile app, it means a store submission prepared so the app store reviews go smoothly.

You own the code, the repositories and the cloud accounts from day one, so there is nothing to hand over at launch. At the end of launch you have a live product and a release process that runs the same way each time.

6. Support

The team that built the product stays to support it. Support means monitoring, fixes and improvements after launch. Bugs found within 60 days of launch are fixed free. The people who fix a problem are the people who wrote the code, so a fix starts from knowing the system.

Improvements come from real usage. On mobile projects we wire in analytics and feature flags from the start, so the roadmap follows how people use the app. Machine learning models ship with versioning, monitoring and retraining, so they keep working after launch.

From here you have a team that already knows your product, and a roadmap that keeps moving.

What we ask of you

Six steps on our side need a few things on yours:

• Someone at the weekly demo who can make decisions. A demo where nobody can say yes or no turns into a status report.
• Access to your users during discovery and design, for the interviews and the prototype tests.
• Early word when your priorities change. The weekly review is the cheapest place to change course.

Where to start

The how we work page sets out the same process, the documents and the engagement models in one place. If you're planning a build, the first call is where it starts. The contact page reaches the people who would scope it, and they would stay with it through support.