Skip to content
How we work

From first call to live.

Four stages, something working to look at every second week, and one team responsible for all of it. Here is exactly what that looks like from your side of the table.

To a written quote
48 h
Between working versions
2 wk
Stages, first call to launch
4
Team, start to finish
1

Last updated

The project

Four stages, no black boxes.

The timings below are the ranges we quote before we know the detail. They get firmer, and they get written down, once we have seen what the work really involves.

  1. 01

    Understand

    1–2 weeks

    Before anyone writes code we work out what the software has to do for your business, who will use it, and what it must not cost more than. The output is a plan specific enough that another company could build from it — which is exactly why it is worth doing properly.

    What you get

    • A written description of what will be built, with the assumptions made visible
    • A price, broken into stages you can start or stop between
    • The three things most likely to cause problems, named up front
    • Agreement on how we will judge whether it worked

    Your part

    Two or three conversations with the people who know how the business actually runs, plus access to whatever exists already — the current system, the reports, the spreadsheets holding things together.

  2. 02

    Design

    2–4 weeks

    You see the actual screens, clickable, before they are built. Changing a screen at this stage costs a conversation. Changing it after it is built costs real money, so we front-load the disagreement.

    What you get

    • A clickable version of the main journeys you can share and test
    • The full set of screens, agreed and signed off
    • Accessibility decided up front rather than patched before launch
    • The awkward states — empty, loading, error — designed, because real software has them

    Your part

    One person with the authority to say yes. Design stalls hardest when feedback arrives from five people who disagree with each other.

  3. 03

    Build

    6–16 weeks

    Two-week cycles, each ending in something you can open and use. No black boxes, and no status report standing in for working software — if a date is going to move you hear it in the demo, not at launch.

    What you get

    • A working version every second week, on a link you can reach
    • Automated testing and monitoring in place from the first cycle
    • Code in your repository, under your licence, from day one
    • A running list of what shipped and what changed

    Your part

    Forty-five minutes every second week to look at the demo, and answers on blocking questions within a working day.

  4. 04

    Launch & support

    Ongoing

    Going live is a milestone, not the end. We move it into production carefully, train the people who will use it, and hand over properly — including the unglamorous parts like what to do when something breaks at 3am.

    What you get

    • A live launch with the way back tested, not assumed
    • Monitoring and alerts your team can see
    • Written handover and a walkthrough with your people
    • A support arrangement with agreed response times, if you want one

    Your part

    A decision on who looks after the software afterwards — your team, ours, or a mix. We plan this stage around that answer.

The rhythm

What the weeks actually feel like.

A process is only worth describing if you can feel it. These four are the ones clients say they notice.

  • Every second week

    A demo, not a status report

    Forty-five minutes of real software running somewhere you can reach it afterwards. We do not use slides for this, because slides cannot be clicked.

  • Continuous

    One shared channel

    Your team and ours in a single group chat. No account manager relaying your question to the developer sitting next to them.

  • Weekly

    Changes explained in plain English

    A short written summary of what changed and why, in language you can forward to someone else without translating it first.

  • Monthly

    We check the numbers together

    We go back to what we agreed success would look like and say plainly whether the work moved it. Sometimes the honest answer is not yet.

Commercials

Three ways to pay for it.

Which one fits depends on how settled your plans are. We recommend the cheapest option that actually works, and say so when that is not the one you asked about.

  • Option

    Fixed-price project

    Best for: A defined piece of work with a budget already approved

    We work out the scope first, quote it once, and carry the risk if it takes longer than we estimated. Best when you know where you want to get to.

    • One price, agreed before the build starts
    • Changes priced separately so nothing is absorbed silently
    • Payment tied to stages you have seen working
  • Most chosen

    Monthly team

    Best for: Work that will keep going after the first launch

    A team reserved for you each month, covering design, development and hosting. Priorities can change every two weeks without renegotiating a contract.

    • Monthly rate, thirty days notice either way
    • The same people throughout, not a rotating bench
    • Priorities re-set every cycle as you learn what matters
  • Option

    Support & maintenance

    Best for: Software that is already live and needs looking after

    Updates, security patches, backups, monitoring and a set number of hours for changes each month. Works on software we built and on software we inherited.

    • Agreed response times for problems
    • Included hours for small changes and improvements
    • A monthly summary of what was done

Fixed price vs monthly team vs support: which costs less?

Comparison of NuovaDev's three commercial models across commitment, risk, change handling, timeline and exit terms
 Fixed-price projectScope already definedMonthly teamScope still movingSupport & maintenanceAlready live
Best forA defined piece of work with an approved budgetWork that continues past the first launchSoftware already running that needs looking after
How you payOne agreed price, billed against stages you have seen workingA monthly rate for a reserved teamA monthly fee covering upkeep plus a set number of change hours
Who carries an overrunWe do — that is what the fixed price buys youShared: you see the burn every two weeks and can re-prioritiseNot applicable — the work is capped by the hours in the plan
Changing your mind mid-buildPriced as a change, quoted before we build itFree — priorities are re-set every two weeksAbsorbed into the included hours, or quoted if larger
Typical commitment6–16 weeksRolling month to monthRolling month to month
Getting outStop between stages; the work to date is yoursThirty days notice either wayThirty days notice either way
What you ownCode, accounts and data, from day oneCode, accounts and data, from day oneCode, accounts and data — including anything we inherited

Prices are indicative until we understand the work. We quote after that first conversation, not before it. Get a Quote

Questions

What people ask about how we work.

How quickly can we start?

Usually within two weeks of agreeing terms. If your deadline is tighter than that, say so on the first call — we will tell you honestly whether we can staff it rather than book you in and hope.

What happens if we want to change something mid-build?

On fixed-price work we price the change and you decide before we build it. On a monthly team the priorities are re-set every two weeks at no extra cost, which is why most longer projects use that arrangement.

Who owns the code and the accounts?

You do, from the first day. The work lands in your repository, the hosting and app store accounts are in your name, and nothing requires our involvement to keep running.

Can you work with our existing developers?

Frequently, and it usually produces the best handovers. Your team can review the work as it happens and take ownership gradually rather than all at once on launch day.

What if a deadline is going to be missed?

You hear about it in that two-week cycle, not at the end. We would rather have an awkward conversation in week six than a surprise in week sixteen, and we bring options — reduce scope, extend, or reorder — rather than just the bad news.

Can we stop after the first stage?

Yes. The first stage is sold as a standalone piece of work with its own deliverables. If the plan concludes the project is not worth building, that is a useful answer, and the plan is still yours to keep.

Start with a conversation.

Thirty minutes, no presentation. You will have a written summary and an indicative plan within 48 hours — and no obligation to go any further.

Request a Consultation

Reply within one business day · You own everything we build · No lock-in