Most of the difficulty is in the operation, not the code.
Our experience comes from systems where software has to hold an operation together — people in the field and at a desk, records that outlive their author, approvals, routes, schedules, integrations and the audit trail behind all of it.
Domain experience does not replace discovery. It makes discovery better.
We are engineers, not management consultants with an industry practice. Nobody here is going to tell you how to run your business.
What familiarity with a domain buys is time. The entities, the workflows, the permission model, the edge cases that turn out to be the actual requirement, the reporting somebody will ask for in month four — those get recognized in the first conversations instead of discovered in the third sprint. The questions are better and they come earlier.
Six domains, and what each one taught us.
These are domains where we have built and maintained working software, not a list of markets we would like to enter.
Transportation & fleet operations
Vehicles, routes and the daily schedule they have to hold.
- Route planning and allocation
- Vehicle and fleet records
- Tracking and telemetry
- Geolocation and operational monitoring
- Schedules that change during the day
- Field and office in the same system
Education
Student, staff and network records, and the routine around them.
- Student records and enrollment
- Staff and school administration
- Transport tied to enrollment
- Document management and reporting
- Portals for schools, families and administrators
Healthcare operations
The operational side of care: who is seen, by whom, and what was recorded.
- Patient and provider records
- Scheduling of appointments and resources
- Care records and documents
- Queues and referrals
- Access profiles and activity logs
Government & public-sector operations
Administrative process, approvals, inspections and the record of both.
- Administrative workflows and approvals
- Inspections and field reporting
- Environmental licensing and compliance processes
- Document control and audit trails
- Role-based permissions across departments
- Dashboards for the people accountable
Procurement & compliance
Opportunities, deadlines, documents and the requirements attached to each.
- Monitoring and tracking opportunities
- Deadlines that cannot be missed
- Qualification requirements and documents
- Alerts tied to operational status
- Contract and document organization
Business operations
The internal systems a company runs on, and the spreadsheets they replace.
- Operational platforms and internal portals
- Request and approval workflows
- Process automation
- Integrations between systems that were never designed to talk
- Dashboards and operational reporting
A route is a promise made the day before.
Our transport work spans planning and operation: routes built against demand, vehicles assigned to them, tracking and telemetry feeding an operational picture, and the field workflows of the people driving and supervising.
A route is a plan; the day is what actually happens. Vehicles come out of service, a stop is added, a driver is replaced, and the people who need to know are in a vehicle rather than at a desk. What makes a system like this useful is not the map — it is how fast the plan can change, how reliably that change reaches the operation, and whether the position data arriving all day becomes something a supervisor can act on rather than a screen of moving dots.
We describe this experience by the engineering problem rather than by fleet size, client or deployment. If your product depends on a specific device, protocol or certification, that is worth establishing in the first conversation.
Someone will ask who approved this, and when.
A significant part of our experience comes from software built for Brazilian public-sector operations — administrative workflows, approvals, document control, inspections, environmental licensing and the dashboards the people accountable actually read. We say that plainly because it is where the depth came from.
What transfers is not the legislation. It is the shape: a system used by departments that do not report to each other, where permissions are a domain rule rather than a settings screen, where a record has to survive the person who created it, and where "we changed it back" is not an acceptable answer to an auditor. Any regulated or multi-stakeholder operation has that shape, and most engineering teams meet it for the first time in production.
We do not hold U.S. public-sector certifications or contracting experience, and we do not present ourselves as a partner for U.S. federal work.
The spreadsheet that became infrastructure.
Most companies run part of the business on something nobody designed: a spreadsheet that grew, a shared inbox used as a queue, an approval that happens because someone remembers to ask. It works until the volume, the headcount or the audit arrives.
Replacing it is rarely a technical problem first. The hard part is finding out what the rules actually are — including the exceptions people apply without knowing they are exceptions — and deciding which of them are real constraints and which are habits worth ending. Our own products in this space are operational platforms and internal systems, which is the same work seen from the inside.
If your operation is in an industry not listed on this page, this is usually the section that describes it anyway.
The same six problems, wearing different clothes.
The industries look nothing alike from the outside. From inside the codebase they rhyme, and this is the part worth reading if your operation is not on the list above.
Permissions are a domain rule
Different roles, different departments, different slices of the same record. When permissions are treated as a settings screen bolted on late, they become the thing that blocks every subsequent feature.
Field and office in one system
Half the users are at a desk with two monitors and half are outdoors on a phone with one hand free and unreliable signal. The same data, two completely different interfaces and failure modes.
Events have to become decisions
Operational systems produce a great deal of data that means nothing on its own. The value is in the small number of views that let someone accountable act today.
Nothing lives alone
There is always another system: a legacy database, a government service, a spreadsheet somebody refuses to give up, an API that changes without notice. Integration is the normal case, not the exception.
Auditability is a requirement, not a log
Who changed what, when, and on whose authority. Designed in from the data model, because it cannot be reconstructed later from application logs.
The exception is the specification
Every operation has cases the process does not cover, handled by someone who knows. Those cases are the product. A system that only supports the happy path gets abandoned in month two.
Industry experience helps. Problem fit matters more.
We do not only work in these industries, and we are not going to claim we serve every one of them. What we look at is whether the shape of your problem is one we have solved before — the permission model, the field operation, the integrations, the auditability.
If it is, the industry label matters far less than it looks like it should. If it is not, that is something to establish in the first call — not in the third invoice.
We describe our experience by the problem solved rather than by client name. Client names are shared under NDA where applicable.
This is context, not an offering.
Domain experience shapes how we work; it is not a separate thing to buy. What you contract is one of four engagements.
What does your operation actually have to do?
Describe the workflow, who depends on it and what it has to connect to. We will tell you which parts we have seen before and which parts we would need to learn — and roughly what learning them would cost.