You've won a grant to build an app. Now what?

Twelve months sounds long. It is not. Choosing a builder takes weeks if you do it properly; scoping takes weeks more; and the report at the end wants outcomes, not intentions. The useful deadline is not the day the grant ends — it is the day the product needs to be in real users' hands early enough to learn something you can actually report.

Work backwards from that day. For what it's worth, our own products have shipped their version one in 65 to 90 days once scoped — the durations are published on each case study — and the commissioning around a build routinely takes as long as people expect the build itself to.

Write the product as ten plain sentences about what a user does with it. Then turn those into a written version-one scope with named exclusions — the list of what it deliberately does not do is the half that protects you. Grant budgets rarely die in one bad decision; they die by drift, and drift starts the day the scope lives in people's heads instead of on paper.

An honest builder will try to cut your scope, not grow it. Treat that as the strongest signal in the room. If everyone you talk to nods along with the full wish list, keep talking to people.

A fixed price against each milestone maps cleanly onto monitoring returns: you can show what was delivered, what it cost, and what comes next. Open-ended day rates are where awards quietly evaporate — not through bad faith, just through nobody being forced to finish anything by a date.

End every milestone with something a monitoring officer could look at: a working demo, a test group using it, a launch. And before you commit a pound, check your award letter — eligible costs and subcontracting rules differ by programme, and your monitoring officer's answer beats anything a studio's blog tells you, this one included.

The asset that survives the grant period is the thing you were funded to create — so make sure it survives in your hands. Code in a repository you own, domain registered to you, hosting and app store accounts in your name, documentation written as a deliverable rather than a favour, and contract terms that say all of it plainly.

Ask any prospective builder what happens if you part ways mid-project. The acceptable answer is boring: you keep everything and another developer picks it up without archaeology. A build whose assets sit in the studio's accounts is a build you rent, and the rent comes due exactly when the grant money is gone.

There is a familiar list that eats award money: a long discovery phase, a brand refresh, a conference stand, a video. Some of it is even eligible spend. Very little of it teaches you what a month of real users does.

So ship smaller and sooner than feels comfortable, and keep a meaningful slice of the budget unspent for what launch teaches you — the first weeks of real use produce the change requests that matter, and the founders who kept room to act on them get twice the product from the same award.

Write the ten sentences. Read your award letter's rules on subcontracting. Then talk to more than one builder, and ask each of them the same things: what would you cut from version one, what does each milestone cost, and what do I own on the day we part ways.

A scope call with us is free and produces the same thing every time: an honest read on what version one needs, roughly what it should cost, and what not to build yet. If that reads like a sales line, notice that it works just as well as a checklist for whoever you end up hiring.