The office app. Scheduling, visits, billing and payroll all work from the same record. Click any number on a dashboard and you can see where it came from and who's responsible for it.
Case study · my own product · 2025–2026 Health dataMany agencies, one systemMinnesota
Health dataMany agencies, one systemMinnesota Software that runs a home care agency, and how I built it.
Accrenza is my own product. I'm showing it the way I'd walk a client through a finished project: what was wrong, what made it hard, what I built and how I went about it.
The problem
A new state rule, and agencies finding out too late.
Home care agencies in Minnesota work on thin margins and a lot of rules. Starting July 1, 2026, the state wants 80% of visits verified electronically, and it checks every quarter. Claims, timesheets and payroll all depend on those visits being right.
Most agencies I talked to keep the schedule in one place, verified visits in another, claims in a third and payroll in a fourth. None of it lines up, so they find out they're short, or that they've billed for something they can't prove, months after the fact.
So the goal I set was simple to say: one system where the schedule, the visit, the claim and the paycheck are the same record, and the person responsible for each number sees a problem before the state does.
What made it hard
Five things I had to get right.
Health dataEvery role sees only what it needs, every account uses two-step sign-in, and every time someone opens a record it's logged. I
wrote those rules down before designing a single screen.
Many agencies, one systemOne agency can never see another's data. The database enforces that itself, so a bug in the app can't leak it.
Rules that keep changingRates, thresholds and deadlines change every year. They live in settings an admin can update, with a record of who changed what.
Working with the state portalAgencies already use the state's free verification portal, and they aren't going to drop it. Accrenza checks each visit first and then
passes it along.
Only meI planned 22 modules and cut 15 features before writing any code. Saying no early is what made it possible to finish.
What I built
Three apps that work as one.
They share one design system, so the office app, the messaging app and the caregiver app look and feel like the same product.
Messaging. Calls, texts, voicemail and email in one inbox, with the client each message is about shown next to it. It won't let staff send health details where they shouldn't. Desktop apps for Mac and Windows.
The caregiver app. Caregivers clock in and out, work through the visit's task list and send a quick report in under a minute. I designed it for a phone first, with one main action per screen.
Screens
A few screens.
1 / 5 Agency dashboard. What the office sees first thing in the morning. Anything with a legal deadline sits at the top.
2 / 5 Master schedule. The day's visits on one board, with open shifts next to them and the hours each client has left.
3 / 5 Claim management. Billing, from the claim to the payment. When a claim is denied you see why and how long you have to fix it.
4 / 5 EVV compliance. The number the state checks: how many visits were verified. Every problem visit is listed until someone fixes it.
5 / 5 Connect inbox. Calls, texts, voicemail and email in one inbox, with the client each message is about shown alongside it.
The AI part
The software suggests. A person decides.
What they doSmall assistants each keep an eye on one area: open shifts, failed visit checks, denied claims, expiring certifications,
overtime. When something needs attention, they suggest what to do and explain why.
Who decidesIn this kind of work a real person has to be accountable. Staff approve, change or reject each suggestion, and they can undo it
afterwards.
The paper trailEvery suggestion and every decision is recorded: who, what, when and why. It's the same record a state reviewer would ask for.
Health data
Treated with care.
You won't see any of this in a screenshot, but it's the first thing I write down on any project that handles sensitive data.
- Walls in the databaseEach agency's records are separated by the database itself. Even a mistake in the app code can't cross that line.
- Two-step sign-in for everyoneOwners and admins included, with backup codes for the day someone loses their phone.
- Only what each role needsA caregiver sees today's visits, not the agency's finances. Someone doing billing sees claims, not diagnoses.
- Every look is loggedWho opened what and when, kept for as long as the rules require and easy to export for an audit.
- Nothing private in notificationsPhone notifications and message previews never show a name next to a health condition.
- Keys kept out of the codePasswords and keys live in a secure vault, and old records are cleared on a schedule the system enforces.
How I built it
Plan first, then small releases.
It's the same process I use with clients. This time I was the client.
01 · PLANWritten down before codingI planned 22 modules and cut 15 features on purpose. Deciding what not to build mattered as much as what to build.
02 · DESIGNEvery screen drawn first112 screens designed before any were coded, so building them was a matter of matching, not guessing.
03 · RELEASESFour working releasesRecords, then visits, then billing, then payroll and accounting. Each one worked on its own before I started the next.
04 · HANDOVERWritten up as I wentNotes on every screen, every route and how the system fits together. What another developer would need on their first day.
Your project
Same approach, sized for you.
Most client work is much smaller than this: a web app, an internal tool, or an old .NET app that needs fixing. The approach stays the same. A fixed price up front, screens you approve before I build them, a demo every week, and a clean handover at the end.