Short cycles, written down.
A project with us moves through five phases. Each one ends with something you keep, and every two weeks you see working software instead of a status report.
01
Usually 1 to 2 weeks
Discovery sprint
We start by understanding the problem before proposing software for it. In workshops and interviews we learn how the work happens today, who is involved, where time and money leak out, and what the first release has to achieve.
On the technical side we look at your existing systems, data, and accounts, and we test the riskiest assumptions early. If an integration is uncertain, we try it now rather than in week eight.
Discovery is useful on its own. If you stop after it, you still hold a plan any competent team could build from.
You receiveEnd of PH-1
- A product brief: goals, users, scope, and what is out of scope
- User flows and a prioritized backlog
- A technical approach and architecture sketch
- A risk register with a plan for each risk
- An estimate range and a recommended engagement model
02
Overlaps the first build sprints
Design
Design starts with wireframes: the structure of each screen and the path between them, kept rough on purpose so it is cheap to change. Once the structure holds, we design the interface in detail and build a clickable prototype.
We test the prototype with people who will use the product, fix what confuses them, and only then hand screens to development. Design continues during the build, one sprint ahead of the code.
You receiveEnd of PH-2
- Wireframes for each flow in the first release
- Interface designs with every state covered
- A clickable prototype you can share
- A component library and design tokens
- Findings from usability sessions
03
Two-week sprints, repeated
Two-week build sprints
The build runs in two-week sprints. Each one starts with planning, where we agree which backlog items fit, and ends with a demo of working software on a real device or browser. Then we look back at what to improve and plan the next one.
Because every sprint ends in something that runs, you can change priorities between sprints without throwing work away. Scroll through the board below to watch one sprint play out.
You receiveEvery sprint
- A demo of working software, recorded for anyone who missed it
- A test build or staging link to try yourself
- An updated backlog and the plan for the next sprint
- Release notes for what changed
To do
In progress
In review
Done
Sample sprint. Ten working days, planning to demo.
04
Usually 1 to 3 weeks
Launch
Launch is planned, not improvised. We freeze scope for the release, run a full regression and accessibility pass, migrate data, and rehearse the release on a staging copy of production.
Mobile apps also go through store review. Apple says that on average, 90 percent of submissions are reviewed in less than 24 hours, but we plan the release date with room for a rejection and a resubmission. After go-live we watch error rates and support requests closely and fix what turns up.
You receiveEnd of PH-4
- A production release on your infrastructure and store accounts
- A release checklist and a rollback plan
- A runbook for deploys, backups, and incidents
- Admin access and credentials handed over to you
- A short handover session for your team
05
Ongoing
Evolve
Software that people use keeps changing: operating systems update, app stores raise their requirements every year, libraries get security fixes, and your users ask for things nobody predicted.
After launch we look at how the product is actually used, fix what gets in the way, and plan the next release with you. A care plan usually fits this phase; a new product sprint fits when the next big piece of work is ready.
You receiveEach month
- Dependency, OS, and app store updates
- Monitoring and bug fixes
- A written maintenance note
- An updated roadmap for the next release
How you stay informed.
You should never have to ask where a project stands. These routines run on every engagement.
Sprint planning
We agree on what the next sprint will deliver, based on your priorities and what we learned in the last one.
Sprint demo
We show working software, not slides. You try it, ask questions, and redirect us if something is off.
Written update
A short note: what got done, what is next, decisions we need from you, and any risk that changed.
Shared backlog
Every task, bug, and idea lives in one list you can read at any time, in priority order.
Decision log
Important choices are written down with the reason, so nobody has to remember why six months later.
Retrospective
We look at how the sprint went and change one or two things in how we work. You are welcome to join.
What we ask of you.
Good software comes from a working partnership. Here is what makes a project run smoothly on your side.
- One decision-maker who can say yes or no to scope and priorities.
- Timely feedback on demos and designs, ideally within a few working days.
- Access to the systems, data, and accounts the software has to work with.
- A few real users willing to try prototypes and early builds.
- Your knowledge of the business, the customers, and the edge cases.
Start with a discovery sprint.
One or two weeks, a written plan at the end, and no obligation to continue with us.
contact@hilltechlabs.com