What the business does
We are a software development company. We are paid to design and build custom web applications, and to host and maintain them afterwards. Our customers are businesses, residents' associations and professional firms, mostly in Kenya.
-
Build
Custom web applications
Built to a signed scope for one client — payment records, member registers, reporting. Charged as a development fee.
-
Host
Hosted software, by subscription
Where a system serves many organisations, we run it as a product and charge a recurring fee per organisation.
-
Maintain
Support and changes
Ongoing maintenance, changes and support for systems we have built, charged monthly or by agreement.
A residents' estate, South B
Service charge for over a thousand households was being run from a spreadsheet, a phone full of M-Pesa confirmations and a WhatsApp group. We replaced all three with one system, and left the treasurer able to answer any question in the meeting rather than after it.
registered
one screen
accounts
on every change
Before
- A spreadsheet per year that one person understood.
- M-Pesa confirmations matched to households by hand, every evening.
- Committee figures assembled from scratch before each meeting.
- Residents chased in a WhatsApp group, with no record of who was told what.
After
- Every household and every month on one screen.
- M-Pesa messages pasted from the phone, read and matched to a household.
- Payments settle the oldest unpaid month first, automatically.
- A statement of accounts generated from the ledger, so it reconciles by construction.
Applicant tracking, built twice
The same engine for a Nairobi hospital group and for a search practice placing executives into American firms. Two hiring processes with almost nothing in common, and one system underneath both.
What hiring looked like
- CVs arriving in an inbox, forwarded on, and lost in the thread.
- A shared spreadsheet listing candidates, edited by three people at once.
- No record of who had been contacted, by whom, or what was said.
- Shortlists rebuilt by hand for every panel, from whatever was to hand.
- Nothing to show a client — or a regulator — about how a decision was reached.
What we built
- One pipeline per role, with every candidate at a named stage.
- Notes and history against each candidate, attributed and dated.
- Shortlists produced from the pipeline rather than assembled from memory.
- Roles as different as clinical staff and an FP&A lead in direct lending, running through the same system.
- A record of how each hire was reached, which is what an audit asks for.
That is the argument for building rather than buying: the second one cost a fraction of the first, because the engine already existed and only the process around it changed.
Other things we have built
- Money
Service-charge ledgers
Charges raised monthly, payments allocated oldest-first, arrears and credit tracked per household.
- Reconciliation
M-Pesa matching
Confirmations read straight from a phone, matched to the right account by payer name, with duplicates refused.
- Records
Member and household registers
Self-registration from a shared link, with the register kept current by the people it describes.
- Reporting
Statements and financial reports
Generated from the ledger rather than assembled by hand, so the figures reconcile by construction.
- Access
Role-scoped portals
Committees, staff and residents each seeing only what belongs to them, with every privileged view logged.
- Messaging
Automated notifications
Receipts and reminders on templates the client edits, with opt-out, quiet hours and a full send log.
How we work
Five steps, in this order. You see something working before you commit to the full build, and you sign off the cost before we write the rest.
Audit the current system
We interview the owners and the people doing the work. They rarely describe the same process, and the gap is where the money goes.
Build an MVP
Something real in your hands inside a week, used against your own data. No invoice and no commitment attached to it.
Sign off the financials
Scope and cost agreed against something you have already used, so nobody is pricing an idea.
Build the full product
The whole system, against the signed scope, built the way it would be built for a company with an audit committee.
Test, then roll out
Run against real data and real staff. Charges begin when the system is live and in use — not on delivery, and not on signature.
How we build
The things that are cheap to build in at the start and expensive to add once you have customers.
- Isolation
One client's data cannot reach another's
Enforced at the model layer, with the tests that prove it written before the feature is.
- Audit
Financial records are voided, never deleted
Who entered it, when, and why it was reversed — on every row.
- Testing
Tested against what we deploy on
Not just the database we develop on. The difference between those two is where the quiet, expensive bugs live.
- Gates
Nothing reaches production unchecked
Static analysis, style and the full test suite run on every push.
- Laravel
- Livewire
- Filament
- Tailwind
- Postgres / SQLite
- Fly.io
- GitHub Actions