Skip to content
Talk to our engineering team

Services

Staff Augmentation Dedicated Teams Product Engineering Software Maintenance

Company

For Agencies Industries Case Studies About Talk to our engineering team
Engineering case studies

See the engineering behind the software.

Anonymized examples of systems PyDen has worked on: the problem each one had to solve, the constraints it was built under, the engineering decisions that followed and what was built. That is what tells you whether we can do it again for you.

Talk to our engineering team See the domains behind these
How we write these

The standard we hold ourselves to here.

Case studies are the easiest page on any engineering site to exaggerate, so it is worth saying up front what these are and are not.

Client identities are withheld

Not every organization wants its systems discussed publicly, and that decision belongs to them. Where a name cannot be published, the problem still can — and the problem is the part that tells you something.

Sensitive operational detail is left out

Some of what makes these systems interesting is exactly what should not be published. Where a detail would expose an operation, it is omitted rather than blurred into something vague.

Numbers appear only when they are verifiable

There are no percentages on this page. A figure we cannot source and publish is worth less than no figure at all, and you have read enough case studies with invented ones to know the difference.

Designed capability is labelled as such

Each case ends with what the system was designed to enable. When we have a measured result we can publish, it will be labelled as an observed outcome and these will not read the same.

Selected work

Five operations, and what made each one hard.

Transportation & fleet operations

Keeping a transport operation on schedule while the day changes it

Challenge

A route is planned the day before and the day disagrees with it. Vehicles come out of service, stops are added, assignments change, and the people who need to know are driving rather than sitting at a desk.

Engineering approach

Treat the plan and the day as two different things: routes and vehicle assignments as records that can be revised, position and telemetry as a stream that has to become an operational picture rather than a screen of moving dots, and a field interface built for one hand and an unreliable connection.

What had to be resolved

  • Position data is continuous and mostly uninteresting — the work is deciding what deserves attention
  • Field and office need the same data through completely different interfaces
  • A change made at the office has to reach a vehicle already in motion
  • Connectivity fails, so the mobile side cannot assume the network

What the system was designed to enable

One operational picture of where the fleet is and what it is supposed to be doing, with plan changes reaching the field the same day rather than the next one.

  • Web
  • Mobile / field workflows
  • Geolocation
  • Tracking & telemetry
  • Operational monitoring
  • Reporting
Education management

One environment for student records, school administration and transport

Challenge

An education network runs several operations that share the same people and refuse to share the same system: enrollment, staffing, documents, transport and the reporting each of them owes upward. The data overlaps; the systems do not.

Engineering approach

Model the student, the staff member and the school as records the whole platform agrees on, then build each operation on top of that instead of beside it — so transport is planned against actual enrollment and a document belongs to a record rather than to a folder.

What had to be resolved

  • Permissions differ by school, by role and by department, and are a domain rule rather than a settings screen
  • Transport allocation depends on enrollment, so the two cannot be separate databases
  • Administrators, schools and families need different views of the same records
  • Reporting has to be reproducible later, not regenerated from memory

What the system was designed to enable

Enrollment, staff, transport and documents held in one system, so a change in one of them is visible to the others instead of being re-entered.

  • Web
  • Role-based access
  • Document management
  • Reporting & indicators
  • Portals
Healthcare operations

The operational side of care: who is seen, by whom, and what was recorded

Challenge

Care delivery generates a queue, a schedule, a record and a referral for the same person, usually in four places. The clinical question is not the hard part for software — the coordination around it is.

Engineering approach

Put the person at the center and hang scheduling, care records, documents and referrals off that single identity, with access decided by role and every read and write leaving a trail, because in an operation handling sensitive data the log is part of the requirement.

What had to be resolved

  • Access is granular by role and has to be defensible after the fact
  • Scheduling competes for people and resources that are finite
  • Referrals cross teams, so a record has to travel without losing its history
  • Sensitive data changes how much of the system can be convenient

What the system was designed to enable

Scheduling, records, referrals and access control in one operational environment, with the activity trail available when someone asks who saw what.

  • Web
  • Role-based access
  • Audit logging
  • Scheduling
  • Reporting & indicators
Regulatory inspection & licensing

Field inspections that have to survive being questioned later

Challenge

A licensing and inspection operation produces decisions that someone will contest. The process runs partly outdoors and partly at a desk, the evidence is collected in the field, and the record has to hold up long after the person who made it has moved on.

Engineering approach

Design the process as a sequence of states with the evidence attached to each one, captured where it happens rather than transcribed afterwards, and make the trail a property of the data model instead of something reconstructed from application logs.

What had to be resolved

  • Evidence is captured in the field and has to arrive intact and attributable
  • A process can pause for months and must resume with its full context
  • Different departments see different parts of the same case
  • Auditability cannot be added later — it is decided when the schema is

What the system was designed to enable

Inspections, documents and decisions held as one traceable process, so answering "who decided this, when, and on what evidence" is a query rather than an investigation.

  • Web
  • Mobile / field workflows
  • Document management
  • Audit trails
  • Workflow automation
  • Reporting & indicators
Procurement & bidding operations

Opportunities with deadlines that do not wait for anyone to notice them

Challenge

Procurement work fails on attention, not on capability. Opportunities appear continuously, each carries qualification requirements and documents, and each has a date that ends the conversation. Missing one is indistinguishable from never having seen it.

Engineering approach

Turn a stream of opportunities into tracked items with state: what was found, what it requires, what is missing, what is due and who is responsible — so the system raises the ones that need a decision instead of presenting a list that has to be read in full every morning.

What had to be resolved

  • Sources are inconsistent and change format without notice
  • A deadline is only useful if the alert precedes the work it implies
  • Requirements attach documents that need to be findable a year later
  • The volume is the point: filtering is the product, not a feature

What the system was designed to enable

Opportunities, requirements and deadlines tracked in one place, surfaced by what needs a decision rather than by what arrived most recently.

  • Web
  • Data ingestion
  • Alerts & notifications
  • Document organization
  • Workflow automation
  • Reporting

Capabilities describe what the system does, not a technology list. We name a specific stack for a project only where we can attribute it to that project.

Across these five

What the work had in common.

Different operations, different users, different decades of technology. Three things were true of all of them.

None of them started from a written specification

In all five, the first real work was establishing what the process actually is — including the exceptions people handle from memory and never wrote down. That is discovery, and skipping it is what makes the second half expensive.

All five had to be defensible after the fact

A student record, a case, an inspection, a bid, a route that was changed. Somebody eventually asks who did what and on what basis, which is a decision made in the data model rather than in the logging config.

Four of the five have users who are not at a desk

The same records reach a phone outdoors on an unreliable connection and a browser with two monitors. Same data, two interfaces, and failure modes with nothing in common.

Using these

Bring us the part you expect to go wrong.

The most useful first conversation is not a walkthrough of your product. It is the constraint you are least sure about — the integration that keeps breaking, the permission model that is already fighting you, the report somebody will demand next quarter.

Those are the parts these five projects were mostly made of, and they are where we can tell quickly whether we are useful to you.

Where this experience comes from

What is the hard part of your operation?

Describe the process, who depends on it and what has to be defensible later. We will tell you which parts we have solved before and which parts we would be learning — and what learning them would cost.

Talk to our engineering team