From discovery to delivery, step by step

The real fear when buying a software project is not that it costs too much. It is paying and then waiting, with no idea whether it is moving, until one day something arrives that is not what you asked for.

That fear is reasonable, and the only way to answer it is to be specific. What follows is how we work, stage by stage, with what you get at each one and what we need from your side.

If you are comparing proposals, this also works as a reference for what to ask anyone.

The discovery call

Thirty minutes, free, no obligation. Its only job is to work out whether there is a problem worth solving with software.

We ask what your team does by hand today, which systems the build would have to talk to, who decides when a decision is needed, and what happens if nothing gets done. That last question sorts things fastest: if the answer is "nothing serious", this is probably not the moment.

What you take away even if you never hire us. A concrete opinion on whether your case is one for building, for buying off-the-shelf, or for fixing the process first. If it is one of the last two, we say so on the call and that is where it ends. That is not generosity: a project starting without fit ends badly for both sides.

From conversation to written scope

If there is fit, the next thing is a written proposal. Not an email with a number: a document you can lay next to another one and read line by line.

It carries the scope with what is in and what is out, the deliverables, the timeline, the investment, the revision policy with the number of rounds, and what happens if the scope changes mid-project. That last point is defined before, not when it happens, because it happens.

It takes a few days and almost always needs a second conversation, because writing the scope is where the questions the first call never got to surface.

Kickoff and planning

Before any code, we settle how the project will run: where the plan lives, how often demos happen, where day-to-day communication goes, and who the point of contact is on each side.

It sounds like bureaucracy and it is the opposite. A project without this agreed spends its first two weeks discovering it, and discovers it badly.

Delivery in verifiable increments

This is the underlying decision, and it is the one that answers the fear at the top.

We do not deliver at the end. We deliver in pieces you can see working, with demos every one or two weeks, and with the code in a shared repository from day one. That is not a gesture of transparency: it is control. A project you only see at the end forces you to trust for months and then accept whatever arrives.

When you see an increment every two weeks, two good things happen. Corrections are cheap, because they arrive while the work is recent. And you discover early what can only be discovered by using the thing, which is usually different from what you asked for.

Before anything reaches production it goes through code review, testing of the full flow, and your own validation that it does what it was meant to do. All three are gates rather than formalities: if one does not pass, it does not ship.

If you want to see this process with its timings, it is on our process page. And if you would rather review it against your specific case, that fits in half an hour.

Delivery and handoff

At close you receive everything, and "everything" has a list:

• The code, in a repository in your name.
• The infrastructure in your name: hosting, domain, database, admin access. It is the most forgotten item and the most expensive one to sort out later.
• The documentation: data model, architecture decisions, deployment procedure.
• The design assets, editable.
• A training session with your team, run by the person who built the system rather than by a generic support desk.

A system your team cannot operate has not been delivered, so training is neither optional nor a video.

The thirty days after

After delivery there are thirty days of support included by default. They cover bugs, minor adjustments and questions, through the same channel and with the same person from the project. It is not a plan quoted separately: it comes included, and our response commitment is three business hours.

What it does not cover is new functionality. That is evolution and gets agreed separately, on a retainer, by project or against a block of hours, whichever suits you.

What we need from your side

This is the part almost no proposal writes down, and it explains most delays.

A single point of contact with authority to decide. Not a committee. Somebody who can answer "yes, like that" in two days rather than two weeks.

Availability to decide. A project generates small decisions every week. When they pile up unanswered, the team either stops or guesses, and guessing is expensive.

Access to the information you already have. Your current data, your real rules, your strange cases. Especially the strange cases: they are what break a system and what nobody mentions in the first meeting.

We name it because it is true: projects slip on pending decisions far more than on technical difficulty. When one of ours has stretched, that is almost always where.

When this process is not for you

If you need something running next week, this will not serve you. A process with written scope and fortnightly demos does not compress into seven days, and anyone telling you it does will hand you something untested.

If your process is still changing every month, likewise. Writing a scope for something undecided is writing fiction, and what is needed first is settling the process.

And if the problem turns out to be too many tools rather than too few, that is a different conversation, and we have it in when you do not need more software. Everything we do is on services, and the questions you can use to evaluate this very process are in twelve questions to ask before hiring an agency.

The discovery call runs thirty minutes, it is free and carries no obligation, and it works as well for ruling this out as for starting. You can book it here.