A fixed first milestone, not an open-ended engagement.
Most agency timelines are a range wide enough to be unfalsifiable. Yours is four stages with a fixed first milestone up front, and a written scope you can hold us to — the specific dates live in that scope, since they depend on whether the work is a site, a migration, or a network.
- 01
Scope
Before work startsWe map what's actually being asked for — a site, an app, a migration, a network — and find the parts that are genuinely hard. You get a written scope with a fixed first milestone, not an open-ended day rate.
- 02
Build
The bulk of the engagementWork ships in checkable increments — a staging site, a test migration, a documented network diagram — so you're seeing real progress throughout, not one reveal at the end.
- 03
Ship
CutoverGo-live, migration cutover, or handoff — whichever applies. You get the credentials, the documentation, and a system that works without us in the room.
- 04
Continue
Ongoing, optionalSome clients keep us on for ongoing administration and support; others take everything in-house at handoff. Both are fine — the documentation is the same either way.
The things worth asking before you commit.
- Do you only build apps?
- No — that's every load-bearing part of the stack a business depends on: websites, applications, office networks, servers, and platform migrations. Most engagements span more than one of these, since the parts rarely fail independently of each other.
- Who owns what you build?
- You do, outright — the code, the configs, the credentials. Work happens in infrastructure and repositories you own from day one, so there is no handover event because there is nothing to hand over.
- Do you support what you build after launch?
- Yes, for as long as you want it. Ongoing server administration and network management are core services here, not an upsell tacked onto a build. Some clients keep us on indefinitely; others take everything in-house after launch. Both are fine.
- How does a platform migration work without downtime?
- By running the old and new systems in parallel until the new one is proven, then cutting over on a schedule you control rather than a fixed deadline we impose. The riskiest migrations are the ones rushed to hit an arbitrary date.