Menu
Start a project

Method

How a software project runs

Five stages, the same five on a three-week job and on a year-long one. Each stage ends with something written that stays with the client.

  1. Discovery

    A call, then a written brief. The brief restates the problem in our words, lists the constraints we heard, and names the risks visible at that point. If the project should not be built, this is where we say so.

    Reading the brief is the cheapest way to find out whether we understood the problem.

    What you receive: A written brief, two to four pages.

    What we need from you: One call, and an hour to read and correct the brief.

  2. Proposal

    A fixed scope with a price and milestones, or a monthly plan with a number of reserved engineering days. Either way it carries an explicit list of what is out of scope, because that list is what prevents the argument in month three.

    What you receive: A proposal with price, milestones and an out-of-scope list.

    What we need from you: A decision, and a signature.

  3. Build in weekly increments

    Working software on a staging environment every week, with the continuous-integration run that produced it. Progress and the evidence for it arrive in the same message.

    A weekly demo sits on the calendar for the length of the project. It is a working session rather than a presentation.

    What you receive: A staging build and a test run, every week.

    What we need from you: Thirty minutes a week, and answers to blocking questions.

  4. Launch

    Deployment on infrastructure the client owns, with monitoring configured and documentation written for the people who will run it. A handover session walks the client's team through the parts they will touch.

    What you receive: A handover pack: runbook, architecture notes, access list.

    What we need from you: The accounts, and the people who will own the system.

  5. Care

    An optional retainer for maintenance and further work, cancellable with thirty days' notice. For software with LLM features the retainer includes running the evaluation set again, because retrieval quality drifts as the underlying data changes.

    What you receive: A monthly note: what changed, what the tests cover, what needs attention.

    What we need from you: A monthly half hour, if you want it.

What stays with the client

Repositories, design files, infrastructure accounts and credentials belong to the client from the first commit. The handover pack exists so a different team could pick the work up without calling us.

Tell us what you are building.

Write in English, French, Romanian or Arabic. Every message gets a written answer within one business day.