The work we do, and the work we won't.
The four practices below describe everything we do, and by extension, everything we don't. If a problem doesn't fit one of these we'll either point you to someone better placed, or tell you plainly that we're not the right firm for it.
Built to do serious technical work, honestly, and at a standard worth standing behind.
How engagements run
The shape is the same across all four practices.
The four practices below differ in what they deliver. The way they're run does not. Every engagement, regardless of practice, follows the same operational structure. Predictable phases, written gates, short build cycles, and a handover posture baked in from the first commit rather than retrofitted at the end.
01 · Phasing
Phased, with written gates.
Discovery, architecture, build, and operate each end with a written deliverable the client signs off before the next phase begins. No phase rolls into the next on momentum alone, and no scope expands without a written addendum and a re-stated fee. The point is to make the engagement falsifiable: at every gate, the client can stop, redirect, or change shape with no commercial penalty.
02 · Cycles
Short cycles, working software.
Build phases run in two-week cycles. Each cycle ends with a working demo deployed to a staging environment the client can use, plus a short status note covering what shipped, what didn't, and what's coming next. No big reveal at the end, no waterfall in agile clothing, no surprise scope discovered at handover that should have surfaced in week two.
03 · Communication
Standing communication.
One named lead from Okenwa Labs, one named decision-maker from the client. Weekly written status, fortnightly demos, and ad-hoc calls when something material changes. We work in Slack or email, whichever the client prefers, and adopt the client's project tooling rather than asking them to adopt ours. The communication overhead is calibrated to be high enough to catch problems early, low enough not to consume the work it's tracking.
04 · Handover
Handover-ready from day one.
Documentation is written as the work happens, not at the end under duress. Code review standards, runbooks, deployment scripts, and operational dashboards are part of the build, not an afterthought. If you ever decide to take the work in-house or hand it to another partner, the handover takes weeks rather than months, and you don't have to commission an "exit" engagement to make it possible.
01 / 04Practice
Software development
Custom applications, internal tools, APIs, and data pipelines. Yours to own from day one. Every line we write should be legible to a team that wasn't involved in writing it.
What this looks like in practice
Most of our development work starts from one of three places: a business that has outgrown spreadsheets and Google Forms, a team that has been quoted an eye-watering figure by a bigger agency, or a founder who needs a working product to take to their first real customer.
We build the thing. We write it properly. We document it. We hand you the keys when it's done, or keep running it for you if that's what you'd prefer. No lock-in. No dependency games.
Typical engagements
- Internal operations toolsreplacing the tangle of spreadsheets, email threads, and brittle Airtable bases that your team has outgrown
- Customer-facing web applicationsportals, dashboards, booking flows, account management, anything your customers need to self-serve
- APIs and data pipelinesmoving data between systems, exposing it to partners, or aggregating it for analysis
- Product MVPsa working first version of a product, built carefully enough to survive its first hundred customers
How we work
Short delivery cycles. Working software at the end of each one. You see real progress every week, not a big reveal at the end. We don't do waterfall pretending to be agile.
We write tests where they matter, documentation as we go, and deploy automatically from the first commit. The boring engineering work gets done, because that's what separates a system you can trust from a system you can't.
Is this the right fit?
A quick check.
Good fit
You have a clear problem, a decision-maker, and a sense of what the solution should feel like, but no engineering capacity to build it.
Good fit
You need something custom, built to keep running, that your team can understand and modify later.
Not us
You want a quick-and-dirty prototype in two weeks for half the cost. Try a bigger team or a no-code tool; we won't do it well at that timeline.
Not us
You need a generic off-the-shelf product (CRM, e-commerce platform, accounting tool). Buy one. Don't build it.
02 / 04Practice
Infrastructure & platforms
The software that runs when people are watching meters, dispatching crews, and managing physical things in places with patchy connectivity and no margin for downtime.
What this looks like in practice
This is our deepest area. It's the software that quietly runs behind utilities, logistics operators, infrastructure projects, and anyone managing distributed physical operations.
These systems are unusual because they have to work in places where the software engineer will never be. They have to handle intermittent connectivity, messy real-world data, hardware that behaves unpredictably, and the fact that when they break, someone's meter doesn't get read or someone's crew doesn't get dispatched.
Typical engagements
- Metering and monitoring platformsingesting data from sensors and meters, surfacing it in a useful form, raising alerts when readings drift
- Field operations toolingmobile-first apps for crews doing work in the field, with offline-capable sync and real-time dispatch
- Utility management softwarecustomer management, billing support, operational reporting for utility operators
- IoT data pipelinesmoving telemetry from devices through processing, storage, and onward into reporting or control systems
Why this matters
Most software firms build for office environments: good networks, modern browsers, reasonable users. Infrastructure software is different. It's used by field crews in the rain, on a tablet running an old Android version, over a 3G signal that drops every fifteen minutes.
Building well for those conditions is a specific discipline, and it's one we know. We've made most of the mistakes already, on someone else's project.
Is this the right fit?
A quick check.
Good fit
You run distributed physical operations (a utility, a logistics business, an infrastructure operator) and the software needs to work where people and connectivity aren't perfect.
Good fit
You have hardware (sensors, meters, devices) generating data, and you need a platform that does something useful with it.
Not us
You need the hardware itself designed and manufactured. We work with the data and the software around it, not the device engineering.
03 / 04Practice
Technology consultancy
Embedded technical advice for founders and leaders who need a straight answer about their technology, not a slide deck and a six-week engagement fee.
What this looks like in practice
Consultancy is where we help you decide, rather than build. We embed with your team for a defined period, look at the technology from the inside out, and write you an honest account of what we find.
Most of what we deliver looks like a short, plainly written document. What's working, what isn't, what it'll cost to fix, and what you should do first. Not a slide deck full of quadrants. Something you can use to make a decision on Monday morning.
Typical engagements
- Architecture reviewsan outside pair of eyes on an existing system, with specific, ranked recommendations
- Technical due diligencepre-acquisition or pre-investment assessments of a target's software, infrastructure, and team
- Stack and vendor selectionhelping you choose between options without the vendor noise
- Delivery leadershiptemporary technical leadership to get a stuck project unstuck, or to bridge a gap between permanent hires
- Team augmentationembedding with your in-house team where you need a specific skill or an extra pair of hands
How we work
Time-boxed. Outcome-based. Typically two to six weeks of concentrated work, ending with a concrete deliverable your team can act on. We don't drift into an ongoing retainer that quietly becomes permanent.
If the consultancy work uncovers something we can help build, we'll tell you. If it uncovers something we can't, we'll tell you that too.
Is this the right fit?
A quick check.
Good fit
You've inherited a system (through a hire, an acquisition, or a previous vendor) and need someone to look at it objectively.
Good fit
You're about to make a significant technology decision and want a second opinion from someone not selling you the outcome.
Not us
You need management consulting, business strategy, or organisational design. Plenty of good firms do that work; we don't.
04 / 04Practice
Systems integration
Making the systems you already have work together, without the expensive rewrite your vendor would prefer to sell you.
What this looks like in practice
Most mid-sized businesses have a collection of systems that were each bought for good reasons (a CRM, an accounting tool, an operational platform, a few spreadsheets) that now don't talk to each other properly. The cost of that disconnect shows up everywhere: duplicate data entry, reporting nightmares, customers slipping through the cracks.
Integration work is the unglamorous but valuable job of stitching these systems together cleanly, so your team doesn't spend their week copying data between screens.
Typical engagements
- Data pipelinesreliably moving data between two or more systems, with the right transformations applied in transit
- Middleware and API gatewaysa layer that lets multiple systems interoperate without each needing to know about the others
- Legacy modernisationwrapping an old system in a modern interface so it can be replaced gradually, not all at once
- Third-party integrationsconnecting your platform to the tools your customers or partners already use
Why this usually costs less than you'd think
Most integration problems don't require replacing systems. They require a careful layer between them. We'd rather build you that layer for a fraction of the cost of a full migration. If the migration really is what you need, we'll tell you that too.
Is this the right fit?
A quick check.
Good fit
You have two or more systems that need to share data reliably, and it isn't happening today.
Good fit
You're being told you need to replace a working system just so it can talk to a new one. You probably don't, and we can help you find out.
Not us
You want an off-the-shelf integration platform (Zapier, Workato, etc.) configured for you. Bring in someone cheaper; we'd be overkill.
If one of these sounds like what you need, tell us about it.
Most useful first conversations are short. A few lines about what you're trying to build, change, or fix is enough to tell whether we're the right firm for the job.