A project runs the same way whether it’s a two-week script or a multi-tenant platform with a mobile companion app. What follows is the actual sequence, from the first message to the day you get the keys.
1. First contact
The person who replies to your message is an engineer, not someone relaying your request to one. That matters because the first conversation is where we ask about the parts of a project that don’t show up in a feature list: who else touches this data, whether more than one kind of user needs to log in, what happens to your existing records, and who holds the accounts the project depends on. A client describes the software they want to see. We’re asking about the syncs, permissions, and integrations holding it together, because that’s usually where a budget goes wrong.
The reasoning behind these questions, with real examples, is in how we scope fixed-price projects.
2. The honest read
Sometimes the answer to “can you build this” is “you don’t need to.” If a template covers it, a short script solves the actual problem, or a smaller first version gets you to the same outcome for less, that’s what we say. We’d rather tell you that on the first call than let you find out later that you paid for more than the problem needed.
3. Written scope
Once we know what’s being built, we write it down twice. The included list covers the features, screens, and integrations the price is buying. The excluded list covers everything a client would otherwise assume comes bundled in: a second login provider, say, or importing an existing spreadsheet, marked out unless it’s explicitly named as in. On most of our contracts, the excluded list runs longer than the included one, because that’s where the disagreements would otherwise have started.
You get this document before any code gets written, and we ask for a plain yes on it first.
4. Fixed price and milestones
The price comes from the scope document, and payments are broken into milestones. Each milestone is tied to a deliverable you can look at and accept, like a working login flow or a checkout that takes a real test card, and payment follows that acceptance rather than a date on the calendar. The full mechanics of how a price actually gets built are on how we price.
5. Build phase
Work happens in short cycles, and you hear from us every few days rather than once a month. Updates are short and plain: what got finished, what’s next, nothing that needs a read of the code to follow. Where a description would take a paragraph, we’ll send a short recording of the thing running instead, since a demo answers questions a sentence leaves open. If something is behind schedule, we say so the day it becomes true rather than the week it becomes obvious. More on why in what five hundred deliveries taught us about client communication.
Anything you want added or changed mid-build gets scoped and priced the same way the original work was, as its own piece, scheduled into the next milestone or its own.
6. QA and delivery
Before anything ships, it gets checked against the scope document itself, item by item, not just against whether it looks right. Anything that surfaced during the build but wasn’t in the original scope gets flagged rather than folded in quietly or dropped quietly.
7. Handover
The repository, the hosting account, the domain, and the documentation get set up under your name while we build, so nothing changes hands at the end that wasn’t already yours. FurnitureAxis runs today on accounts the client has held since before launch. Nothing about keeping the project running afterward depends on keeping us around.
8. After
Some clients want an ongoing engagement: maintenance, new features when they come up. We do that. Others want a clean handoff and no further contact, and we do that too. The project tells us which one fits, and handover looks the same either way, since ownership was never conditional on what happens next.
For the reasoning behind why we work this way, see story and values. If you’re ready to start the first conversation, get in touch.