Process
Nine stages, with real decision points. You can stop after discovery with something useful in hand, and you own everything at every stage.
End to end
Thirty minutes, free, and genuinely a conversation rather than a pitch. We want to understand what you do, where the friction is, and what you have already tried. You should leave it knowing whether it is worth going further.
The paid discovery sprint. We map the process you actually run — not the one on the org chart — including the steps that only exist in someone's head and the workarounds nobody has written down. This is where most of the real decisions get made.
Discovery produces a written scope separating version one from later, and a fixed-price proposal broken into milestones with dates. If the honest recommendation is that you do not need custom software, that is what the proposal says.
Screens and flows for the paths that carry the most traffic or the most risk, resolved while they are still cheap to change. Not a full design system — enough to agree how the software behaves before it is built.
Build runs in milestones. Each one ends with working software you can actually use, deployed somewhere you can reach, rather than a status report. Weekly updates say what moved, what did not, and what is next.
Automated tests around the logic that would be expensive to get wrong, and manual testing on real devices for anything mobile. Testing is part of the milestone, not a phase bolted on at the end when the budget is gone.
Software goes live in accounts registered in your name — cloud hosting, domains, and Apple and Google developer accounts. App store submissions are prepared carefully, and we handle resubmission if review comes back with changes.
Written setup and architecture documentation, plus a recorded walkthrough. The test is simple: another developer should be able to pick this up without talking to us. That is what makes the software genuinely yours.
Optional and monthly. Dependencies and platform requirements tracked and applied before they force your hand, monitoring with alerts, and a defined route for reporting problems. Cancellable monthly, because you already own everything.
What to expect
These are commitments, not aspirations. If any of them stops being true, the project has a problem worth raising.
A short written update every week: what moved, what did not, and what is next. Not a formal report — enough that you are never wondering.
Each milestone ends with working software and a review. You approve it before the next one starts, which means you have a natural stopping point roughly every two to three weeks.
Anything outside the agreed scope becomes a written change request with its own price and schedule impact, before it is built. Scope creep is a communication failure, not an inevitability.
Changes are welcome and normal — projects that never change usually mean nobody is learning anything. They just get priced and scheduled explicitly rather than absorbed silently.
Automated coverage on the logic where failure is expensive, plus real-device testing for mobile. We will tell you what is covered and what is not.
Cloud, domain, and developer accounts are registered to you from the start. You are never in a position where leaving requires us to hand something over.
Discovery is one to two weeks. Build depends entirely on scope — and any number quoted before discovery is a guess. What discovery produces is milestone dates you can hold us to, rather than a single optimistic figure.
No. Approval is Apple's and Google's decision and nobody can promise it. What we can do is prepare properly: privacy declarations matching real behaviour, correct entitlements, and a working restore-purchases path. Most rejections are about those. If one comes back, handling the resubmission is part of the work.
Fixed-price milestones mean a scoping mistake on our side is our cost, not yours. If scope changes because requirements changed, that is a written change request agreed in advance.
No — that is what discovery is for. Arriving with a fixed specification is often worse, because it usually encodes assumptions nobody has tested yet.
Then you can. You own the repository, the accounts, and the documentation, and the handover test is that another developer can pick it up cold. That is deliberate — being hard to leave is not a business model we are interested in.
Most during discovery, where a few hours of your team's time saves weeks later. During build, a weekly check-in and a milestone review is usually enough.
Let's turn it into a clear, buildable plan. A first call is a conversation about your workflow — not a sales pitch, and not a commitment.
Prefer email? Contact@DeviceBytes.com