Healthcare product engineering
The same engineering, done by someone who already knows that a file which parses cleanly can still be wrong. You stop paying a vendor to learn the domain on your time.
Services
Web applications and internal tools.
The systems a business actually runs on — dashboards, admin and back-office tools, portals, queues and workflow. Usually replacing a spreadsheet, a manual process, or software that has outgrown what it was built for.
Where this usually starts
Three people keep their own copy of the same workbook and two of them are out of date. A process works because one person remembers which exceptions apply. Somebody rebuilds the same report by hand every Monday morning. Or the system you bought six years ago now decides how you work, rather than the other way round. Nobody planned any of this; it accumulated.
What this is
The hard part of an internal tool is almost never the interface. It is the model underneath: what a record can be, which transitions between states are legal, who is allowed to make them, what happens when two people act on the same record at the same time, and what the system does when somebody does the wrong thing at the wrong moment. Get that right and the screens are comparatively straightforward. Get it wrong and no amount of interface work will rescue it.
So the early part of an engagement goes on the work itself, usually in a room with the people who do it — including whoever maintains the workbook that quietly holds the process together. The exceptions they mention almost as an afterthought are not edge cases. They are the requirement, and they decide the shape of the data model. What comes out of that is a set of states and a permission model we can show you before anybody writes production code.
How we approach it
What we think doing this well requires.
Design the states, not the screens
A record that can be draft, submitted, approved, reversed or cancelled has five states and a fixed set of legal moves between them. Decide those and the interface follows. Start with the interface and you will be discovering illegal states in production for a year.
The awkward path is the real requirement
The override. The retrospective correction. The record cancelled after it was already approved and partly acted on. Nobody mentions these in the first meeting and they are what the system will actually be judged on.
Permissions belong on the server
Hiding a button is a courtesy to the user, not a security control. Access is enforced where the data lives, so a request that should not be allowed is refused regardless of which screen it came from or who crafted it.
Data integrity over convenience
Constraints in the database, not only in application code. Money and quantities in types that do not quietly lose precision. Transactions where a partial write would leave the books wrong.
An audit trail from day one
Who changed what, when, and what it was before. Retrofitting this after somebody asks a hard question about last quarter is expensive and always incomplete. Building it in at the start costs very little.
Maintainable after we leave
Boring, widely-known technology. Conventional structure. Comments where the reason is not obvious from the code. The test we hold ourselves to is whether a competent developer who has never met us can pick it up and be useful in a week.
What you get
Everything on this list is a deliverable, not an extra.
- A documented data model, and the workflow and states it encodes
- Design of every screen, including the empty, loading, error and permission-denied states
- Source code in your repository, with a commit history somebody can read
- A role and permission model, enforced on the server
- Development, staging and production environments, genuinely separated
- Database migrations, so schema changes are repeatable rather than manual
- Deployment, monitoring, and a runbook for the things that go wrong at three in the morning
- Documentation and a handover to whoever maintains it next
Fit
Whether this is us.
Most unhappy projects were mis-scoped at the start rather than badly built. It costs nothing to be straight about this now, and it saves us both a call.
Best suited to
- Your process is understood by the people who run it, but it is not written down anywhere except in their heads
- A workbook that one person maintains has quietly become critical infrastructure, and everybody knows it
- The tool you bought years ago now dictates the workflow instead of supporting it
- The answer to "how do we know that figure is right" is currently "because somebody checks it by hand"
Probably not us if
- You want the cheapest possible quote. We are not the cheapest, and competing on that produces software neither of us would be pleased with in a year
- You need a team of twenty starting on Monday. We are small and staff engagements with senior people, which scales slowly on purpose
- Nobody on your side has time to answer questions about how the process actually runs. That is not a scheduling problem — it is the project's main input
Related
Next to this.
Websites
Marketing sites, content sites and landing pages built for speed, accessibility and search. A site with one job it does well, that your own team can edit.
Healthcare software
Where this work goes deepest: claims and billing workflows, data exchange, reconciliation, audit trails and the formats healthcare actually runs on.
Tell us what you are trying to build.
Describe the problem in your own words. If we are not the right firm for it, we will say so.