Services
What we build, run, and rescue.
Four kinds of system we build, and the work that keeps software healthy once it is live. Each one says what it covers, what you end up owning, and how it is bought. If your problem is not on this page, say so on the call and we will tell you whether it is ours to solve.
01 / Pillar
Property and tenancy platforms
The system of record for a property operation, where occupancy, arrears and upkeep have to agree, from the first lease to the month-end statement.
Portfolios where occupancy, arrears and upkeep all have to agree with each other, and the owner checking is often somewhere else entirely. We build the system of record for the whole operation: who occupies what and on which terms, what each tenancy owes and has paid, what needs fixing and who has been sent, and the statement an owner reads at month end. Arrears are worked out from the ledger rather than typed in, so every figure on that statement traces back to a record.
What you get
- A data model for portfolios, tenancies and their terms, documented in your repository
- Arrears derived from the ledger, never typed in, so every balance traces back
- Repairs and upkeep tracked from the first report to the closed job
- Owner statements generated at month end from the same records
- Role-based access for owners, managers and staff, with an audit trail
02 / Pillar
Booking and scheduling engines
Engines that hold finite capacity against competing demand and refuse an impossible booking before it is made.
When two things cannot happen at once, the calendar is the business. We build the engines that hold finite capacity against competing demand. Availability is worked out from rules rather than typed into a grid. A booking is checked and held in one step, so two people cannot take the last slot. Time zones, cancellations, changes and no-shows are handled on purpose rather than discovered. Then the result goes where it has to: a confirmation to whoever needs telling, a charge to whatever needs charging, and a record of every change.
What you get
- Availability rules your staff can change without a developer
- Conflict checks that run inside the booking, not after it
- Cancellations and changes handled by the person who booked, with the history kept
- Confirmations and charges triggered by the booking itself
- Reports on capacity used, cancelled and left empty
Free, no call required
The scheduling conflicts checklist
24 questions to run against your own booking or scheduling system, from double booking and resources other than people to cancellations, overrides and whether the money still agrees with the calendar.
03 / Pillar
Operations and compliance platforms
Platforms for work that has to be proven: structured capture, qualifications that expire, findings that stay open, and a trail an auditor can follow.
Work that has to be proven, not just done. We build the platforms that capture it in a structured form where it happens, check that the person doing it is qualified on the day they do it, keep every finding open until someone with the authority closes it, and keep a trail that answers who did what, when, and under whose authority. Reports come off the same records as the evidence, so the two cannot disagree.
What you get
- Structured capture for work done in the field, on the device people already carry
- Qualifications tracked against their expiry dates, with warnings before they lapse
- Findings and corrective actions that stay open until someone signs them off
- Role-based access, and an audit trail of every change
- Reports built from the same records as the evidence
04 / Pillar
Payments and reconciliation
One ledger that balances, however the money arrives: mobile money, bank transfer, or cash written down after the fact. M-Pesa Daraja end to end.
Money arrives in more ways than it should: mobile money, bank transfer, and cash written down after the fact. We build the layer that turns all of it into one ledger that balances. That means M-Pesa Daraja end to end, callbacks and failure modes included, bank payments matched against what was expected, cash recorded with who recorded it, and every payment allocated against what was actually owed. Anything that cannot be matched waits for a person to decide, rather than disappearing into a balance.
What you get
- An M-Pesa Daraja integration, with callbacks and their failure modes handled
- Bank and manually recorded payments landing in the same ledger
- Allocation rules that apply each payment against what was owed
- A queue for payments that cannot be matched automatically
- An audit trail and reports your accountant can work from
Free, no call required
The payment reconciliation checklist
35 questions to run against your own payment reconciliation, from partial payments and duplicate callbacks to suspense ageing and whether the ledger ties to the bank statement.
05 / Pillar
SaaS product development
For a product outside those four: we design and build multi-tenant SaaS, from the data model to billing and the admin side that keeps it running.
We take a product from a data model on a whiteboard to something paying customers use every day. That means multi-tenancy, roles and permissions, billing, the admin back office you will live in, and the operational work that keeps it upright after launch. We build in small increments with tests and CI from the first commit, so you see working software every week instead of a status report.
What you get
- An architecture and data model documented in your repository
- A multi-tenant application with role-based access and an admin back office
- Automated tests and a CI pipeline running on every commit
- Staging and production environments, with deploys and rollbacks written down
- A handover pack: runbook, credentials, and how to change things without us
06 / Pillar
Modernization and rescue
For systems that still earn money but nobody wants to touch. We stabilise first, then modernise in steps you can pause.
For systems that still earn money but nobody wants to touch. We read the code, the data, and the infrastructure before proposing anything, then stabilise what is actively breaking, then modernise in steps you can stop after any one of them. The system stays live throughout, and every step has a way back.
What you get
- A written audit of the code, data, and infrastructure
- A stabilisation pass before any rewrite is discussed
- Tests around the parts that cost money when they break
- A staged migration plan, priced step by step
- The system live throughout, with a rollback at every step
07 / Pillar
DevOps and cloud operations
Pipelines, environments, and infrastructure set up so a deploy is routine and a rollback is one command.
We set up the path from a commit to production and make it boring. Pipelines, separate staging and production, infrastructure written down as code, backups you have watched being restored, and alerts that reach a person rather than an inbox nobody opens. We work with the cloud you are already on rather than moving you to ours.
What you get
- CI/CD pipelines with separate staging and production
- Infrastructure defined as code, in your repository
- Backups with a restore we have run in front of you
- Monitoring, logging, and alerting that reaches a person
- A runbook for the routine jobs: deploy, roll back, restore, rotate keys
08 / Pillar
SLA maintenance and support
A retainer that keeps software patched, monitored, and answered for, with response times written down.
A monthly retainer that keeps software patched, watched, and answered for, whether we built it or not. Response times sit in the agreement by priority, so you know what a P1 buys you before you need it. Each tier includes engineering hours for the small changes that would otherwise queue up behind a quote.
What you get
- Response times per priority, in writing
- Dependency and security patching on a schedule
- Uptime and error monitoring, with alerts reaching a person
- Included engineering hours each month for small changes
- A monthly report: uptime, incidents, patches, hours used
09 / Pillar
Our own products
We run our own SaaS, rentiQ, on the same stack and the same discipline we sell, M-Pesa integration included. The lessons come back into client work.
We run our own SaaS on the stack and the discipline we sell. rentiQ is a property management platform for the Kenyan market, live in early access, built and operated by the same engineer who does the client work. It reconciles M-Pesa rent against invoices, which means we have shipped a payments integration that has to be right about somebody else's money. Running it is how we know what year three of a product costs, not just the first sprint: the migrations, the support load, the invoice from the cloud provider.
What that proves
- rentiQ: a property management platform for Kenya, live and taking real use
- A production M-Pesa integration, reconciling real rent against real invoices
- Built and operated by the same engineer who ships client work
- Running costs, migrations, and support load we have paid for ourselves
Next step
Tell us which one you need.
Bring a schedule that keeps colliding, work you have to prove, payments that will not reconcile, or a live system that needs someone to answer for it. If we are the wrong studio for it, we will say so on the first call.
The first call is free and takes 30 minutes. We reply within one business day.