Products
Start from working software, not an empty repository
Seven turnkey products, designed and built by our in-house team on an API-first architecture. Every one is self-hosted on your server, customisable down to the interface, and extendable with new modules. You skip the months a build spends getting to a first working screen.
The seven
Products we built, run and still maintain
Each one is a codebase our own team wrote, which is why changing it is normal engineering work rather than a workaround. Three are released open source; four are commercially licensed. All seven deploy to your own server.
GegoK12
School management for K-12 institutions: admissions, attendance, academics, examinations, fees and parent communication.
Open source · MIT
ChurchCMS
Congregation, membership and church administration management for faith organisations.
Open source · MIT
BloodBank.software
Donor registry, blood inventory and blood bank operations management.
Open source · AGPL-3.0
BOQ Manager
Construction ERP — Bill of quantities preparation, rate analysis and estimation for construction projects.
Commercial licence
ChemTracker
Chemical Labeling Software — Chemical inventory, safety data sheet management and EHS compliance recordkeeping.
Commercial licence
eTender
Multi Supplier, Multi Company — Tender publication, bid submission and evaluation workflow.
Commercial licence
Daybook
Daily transaction, cash-flow and operations recording for businesses running multiple shops or locations.
Commercial licenceProduct engineering
Turnkey where it should be, engineered where it matters
Configuring what already fits. Building what doesn't.
Most turnkey software asks you to change how you work. These products don't, because we hold the source and the people who wrote it. Product engineering is what happens between the standard product and the system your organisation actually runs, and it moves through three stages.
Configure
Fitting the product to how you already work
Fields, workflows, approval chains, roles and permissions, report layouts, notification rules and business logic are set to match your process rather than a generic one. This is settings work, not development, and it accounts for more of a typical deployment than clients expect.
What matters is knowing where the line falls. Every product ships with a documented boundary between what is configurable and what needs code, and we give you that boundary during discovery instead of discovering it mid-project.
Redesign
Replacing the interface without touching the core
The design is not fixed. Because every product is API-first, the interface consumes the API rather than being fused to it, so it can be restyled to your brand, rebuilt against your own design system, or extended with a separate mobile app while the underlying system stays exactly as it is.
Our team designs before the API exists. Requirements are worked through with your product owner, wireframes and screens go through UX review and rework, and the backend team then supplies the API to the interface that was agreed. Screens are shaped by your process, not by whatever the backend happened to return.
Extend
Building only the part that is specific to you
New modules, new integrations, new reporting. Extensions consume existing endpoints rather than reaching into the database, which is what allows them to survive upgrades instead of breaking at every release.
The spine every system needs — authentication, roles and permissions, audit trails, notifications, reporting, tenancy — is already written and already running in production. Your budget goes to the part nobody else has, rather than to rebuilding the part everybody needs.
That is where the saved development time comes from. Not from templates, and not from working faster, but from starting at a system that already runs and is maintained by the team changing it.
Engagement
How a product engagement runs
Five stages. The branch strategy decision is the one most vendors leave out, and the one that determines your maintenance cost for years afterwards.
01
Discovery
Your process mapped against what the product already does. The output is a written gap list, not a proposal deck.
02
Gap analysis
Each gap classified as configuration, extension, or core change. Core changes are the expensive ones and we say so here, not later.
03
Branch strategy
Decided up front: does your deployment track our releases, or fork away from them?
04
Build
AI-assisted. Our engineers use Claude Code daily for scaffolding, test generation, static analysis triage, refactoring, documentation and review passes. AI does not approve merges, choose architecture, or deploy to production.
05
Handover
Deployed on your server, documented, with a stated position on how future releases reach your instance.
Honest limits
When starting from an existing product is the wrong call
- Your process differs from the product's core assumptions in a way that touches the data model. Bending the schema costs more than a clean build and leaves you unable to take upgrades.
- You need behaviour changed for every other deployment, not just yours. We will not do that, and the fork it creates becomes your maintenance burden.
- You want the screens but none of the workflow. That is a rebuild wearing borrowed clothes.
- You need a compliance certification we do not hold. Ask before you start, not after.
If any of these describe your situation, say so on the first call. We will tell you whether a new build is the better route, including if the answer is that we are not the right firm.
Next step
Request a demo and pricing
Tell us which product you are looking at and what you are replacing — a spreadsheet, a legacy system, a paper process. You will get a walkthrough, a view on what would be configuration versus custom development, and pricing for your deployment.