We build the internal software that holds an organisation's operational data — the registers, case files, work pipelines and directories that everything else depends on. Designed for teams whose records are consequential and whose access has to be provable.
Line-of-business software usually fails in the same predictable places. These are the ones we build around first, rather than retrofitting later.
Every row keeps the name of the file, form or import it arrived from. When someone questions a figure, the answer is one click away instead of an afternoon of archaeology. Nothing is silently corrected on the way in.
Roles are a module, an action and a data scope — not a hardcoded list. An administrator can create a role, narrow it to one location, hide individual fields and switch off bulk export without waiting for a release.
Status, assignment and resolution live alongside the original record rather than replacing it. The register as it was received stays intact, which matters the first time anyone has to reconstruct what was known and when.
Figures are computed live from the source tables, and every summary drills through to the rows behind it. Where the underlying data is incomplete, the interface says so rather than presenting a confident total.
Most of the risk in this kind of project sits in the data, not the interface. We front-load it.
Before any schema is written, we work through the spreadsheets, registers and exports already in use. Duplicate copies, inconsistent spellings and columns that disagree with each other are catalogued rather than assumed away.
A schema is generated from the real files and checked against them, so the row counts match on the first import. Anything ambiguous is raised as a question for the people who created the data, not resolved by guesswork.
Permissions, scoping, field-level restrictions and the audit trail are built and tested before the first screen. Retrofitting them is expensive and usually incomplete.
One workflow, running properly, in production, alongside the existing way of working. Systems that launch complete tend to be abandoned complete.
Hosting, database and credentials sit in accounts you own. Schema, import scripts and tests come with the build, so you are not dependent on us to keep it running.
These are engineering positions, not policy statements. Each one is testable, and we expect clients to test them.
Scoping is a query predicate, not an interface filter. A request for a record outside a user's scope returns nothing — the system does not confirm that records it will not show you exist.
Restricted columns are withheld before serialisation. The value is absent from the response rather than hidden by the client, which is the difference between a control and a decoration.
Reads, reveals, exports and permission changes are recorded with the person who performed them. Where an action will be logged in a way a user might not expect, the interface says so.
Bulk export is a permission, watermarked with the name of whoever ran it, and logged whether it succeeds or is refused.
Sensitive fields are switched off for every role until someone deliberately turns them on. Identifiers are stored partially where a partial value is enough to do the job.
Consent provenance, retention and deletion are treated as part of the schema. Under India's DPDP Act 2023 they are obligations, and they are far cheaper to build in than to add.
Nothing here is novel, and that is deliberate. These are components your team can hire for and your successors can maintain.
Import routines that are safe to re-run, so a corrected source file becomes a one-command reload rather than a fresh project.
Dense tables built for people who read them all day, on modest hardware and unreliable connections. Multi-script text handled properly.
Test suites that assert the access rules hold, so a later change cannot quietly remove a restriction without something failing.
A description of the spreadsheets and registers you currently rely on is usually enough for a first conversation.
