How we work
Seven steps, and you always know which one you are on
Software projects go wrong quietly, in the gap between what was agreed and what was assumed. This process exists to keep that gap visible and small.
Free, about an hour, no obligation.
You describe what is not working. We ask a lot of questions about the operation rather than the technology, and at the end we tell you honestly whether this is something we should build, something you should buy, or something you should leave alone for now.
- What the week actually looks like
- Who is affected and how often
- What success would look like in numbers
- Rough budget range and timing
One to two weeks. Paid, and deducted from the project if you proceed.
We spend time with the people who do the work - in the warehouse, at the counter, in the field. We document the real process including the workarounds, then agree what the system must do and, just as importantly, what it will not do.
- Process map of the current operation
- Written scope with clear boundaries
- Delivery plan and milestones
- A fixed price you can take to a board
One to three weeks depending on scope.
Screens and flows you can click through before any production code exists. This is the cheapest point to change your mind, so we push hard for feedback here rather than after the build.
- Clickable prototype
- Data model and integration plan
- Review sessions with the people who will use it
- Sign-off before build starts
Two-week cycles, for as long as the scope needs.
Each cycle ends with something working that you can open and use. You see progress continuously instead of waiting for a launch date, and changes get made while they are still cheap.
- Demo at the end of every cycle
- A shared board showing what is done and next
- Direct access to the team building it
- Automated testing as we go
One to three weeks.
Real data, real devices and real network conditions - including the bad ones. We test what happens when the signal drops mid-form, when two people edit the same record, and when somebody enters something nobody expected.
- User acceptance testing with your staff
- Performance testing on mid-range phones
- Security review and access testing
- Backup and restore rehearsal
Usually one week, sometimes phased by site.
Data migration, go-live and hands-on training. We stay close for the first weeks, because the questions that matter only appear once people are using the thing for real.
- Data migrated, cleaned and reconciled
- Training for staff and for administrators
- Written guides in English and Swahili where useful
- Support on site or on call during go-live
Ongoing, and entirely optional.
Monitoring, support and a steady stream of small improvements. After a few months of real use you know what you actually need - which is almost never what anybody predicted at the start.
- Uptime and error monitoring
- Helpdesk for your team
- Monthly report and improvement backlog
- Handover to your own team whenever you want it
Working together
What we need from you
The projects that go well have three things in common, and none of them are technical.
- One person who can decide. Not a committee. Someone who can settle a question in a day rather than a fortnight.
- Access to the people doing the work. A few hours of a warehouse supervisor’s time in week one saves months later.
- Honesty about the workarounds. The unofficial spreadsheet is not embarrassing. It is the most useful document you own.
In return you get a named team, a demo every two weeks, a written scope you can hold us to, and a straight answer whenever you ask where things stand.
Technologies we use
A stack chosen to be maintainable, not fashionable
Everything here is something your next developer can pick up. No exotic dependencies you cannot hire for in Tanzania.
Next step
Want a clear quote, not a guessing game?
Tell us your team size, the tools you already run, and where you are headed. We will come back with a scoped recommendation and a real number - usually within two working days.