Devora
How we work

Five phases, no surprises.

Most app projects fail on communication rather than code. This process exists to make the state of the work impossible to misread — mainly by putting it on your phone every week.

Prototype by

Week 3

First real build

Week 6

Typical launch

Week 16–24

012 weeks

Discover

We work out what the app is for, who carries it, and what has to be true for it to be worth building.

Two weeks, paid, and it ends with a document you own whether or not you continue with us. We interview your users — not your stakeholders' impression of your users — map the flows that matter, audit any existing product, and put a costed shape on the work. Roughly one in six discovery engagements ends with us recommending something smaller than the project that was briefed.

What lands at the end

  • Product definition & scope
  • User research findings
  • Technical feasibility assessment
  • Costed delivery plan

What if discovery says the project is wrong?

Then you have spent two weeks instead of six months finding out, and you own the document that explains why.

023–5 weeks

Design

Every screen, every state, every transition — specified before production code starts.

We design the whole surface, including the parts nobody enjoys designing: empty states, error states, offline states, the moment a payment fails. Interactions that are hard to judge in a static file get prototyped in code on a real device. The output is a tokenised design system, in light and dark, built from the same component names the engineers will use.

What lands at the end

  • Complete screen designs, light + dark
  • Interaction prototypes on device
  • Tokenised design system
  • Motion & accessibility specification

Do we get to change our minds?

This is the phase for it. Changing a screen here costs a day; changing it in week fourteen costs a fortnight.

038–16 weeks

Build

Two-week cycles, a build on your phone every Friday, and no surprises at the end.

Engineering runs in two-week cycles against the plan from discovery. Every Friday a build lands in TestFlight and the Play internal track — not a demo, the actual app. You get a written note on what moved, what slipped and why. Performance budgets and crash gates run in CI from the first week, so quality is a constraint rather than a phase.

What lands at the end

  • Weekly builds on real devices
  • Automated test & performance gates
  • Fortnightly written progress notes
  • Production-ready backend & APIs

How do we know it is actually on track?

Because it is on your phone. A schedule can be optimistic; a build you can open cannot be.

042 weeks

Launch

Submission, review, staged rollout — with someone awake at every stage of it.

We prepare the store listings, screenshots and preview video, handle submission to both stores, and manage review including any rejection or appeal. Release goes out in stages behind crash gates, so a regression reaches five percent of users and stops. Someone from the delivery team is on call for the whole of launch week.

What lands at the end

  • Store listings & assets
  • Submission and review management
  • Phased rollout with crash gates
  • Launch-week on-call cover

What if Apple rejects it?

We write the appeal and make the change. It is included, and it is normal — most first submissions get flagged for something.

05Ongoing

Evolve

OS migrations, performance regressions and the next twelve months of roadmap.

iOS and Android each ship a major version every year, and both reliably break something. Retained teams handle those migrations before your users notice, triage crashes against an agreed SLA, and deliver roadmap work at a fixed monthly cost. Every engagement is also written to be handed over — if you build an internal team, we help you take it.

What lands at the end

  • Annual OS migration cover
  • Crash triage against SLA
  • Roadmap delivery
  • Handover documentation

Are we locked in?

No. You own the code from the first commit, the documentation is written for someone who is not us, and there is no exit fee.

What you can hold us to

Four things that never move.

A build every Friday

From week six, a real build lands in TestFlight and the Play internal track. Not a demo — the app.

Written progress notes

Every fortnight: what moved, what slipped, and why. In writing, so it can be forwarded.

One team, start to finish

The people in the pitch are the people who build it. No handover to a delivery pod you have never met.

Your repository, your code

You own everything from the first commit, and the documentation is written for someone who is not us.

Book a discovery call