The app had already been built twice. When I came in, the biggest problem wasn't the code.
What I found
A previous team had already spent a lot of time building the app, but they couldn't get it working properly.
At first, it looked like an engineering problem.
It wasn't.
The business rules hadn't actually been worked out.
Mamacare has several ways of calculating the cost of a booking. It can depend on the number of children, the number of people being cared for, the number of hours, and discounts when multiple children are involved.
All of those things were mentioned in the requirements.
What wasn't clear was when each rule should apply or how they should work together.
So developers had been building screens without having a definite answer to basic questions like:
"How much should this booking cost?"
That's a difficult problem to solve with code when the business itself hasn't decided the answer yet.
The screens can still look finished, though. That's what had happened here.
I stopped building for a while.
Instead of guessing the missing rules, I went through them with the owner.
We looked at the different booking types, discounts, multiple children, hourly pricing and extensions until each situation had one clear answer.
Some of the hardest questions were about combinations.
For example, if a booking is charged hourly and has multiple children, how does the discount affect the hourly rate?
Or if a booking is priced per child, what exactly happens when the number of children changes?
None of this produced anything visible in the app.
For a few weeks, there weren't many new screens to show.
But once those decisions were made, I finally had something I could actually build against.
That ended up being the difference between guessing what the product should do and building what the client actually wanted.
Payments
Once the pricing rules were clear, the next problem was getting the money to the right people.
Mamacare is a marketplace, so I used Stripe Connect.
Caregivers have their own connected accounts. The platform takes its share, and the caregiver eventually receives their payout.
That also means a caregiver can't just start receiving money immediately. They need to go through onboarding and verification first.
So the payment flow wasn't simply:
customer pays → done.
There was a whole onboarding and verification process sitting in the middle.
Booking extensions
One of the more interesting cases was extending a booking while it was already in progress.
A parent can decide to keep the caregiver for another hour, but the price of that extra time depends on how the original booking was calculated.
An hourly booking and a per-child booking don't get extended in the same way.
It's another example of why the business rules had to be settled before the implementation.
Once the rules were clear, the code was much easier.
Screening caregivers
Caregivers also go through Checkr before they can take bookings.
The screening isn't instant. Checkr processes the check and sends the result back later, so the backend has to handle that asynchronously.
I used webhooks to receive the result and update the caregiver's status.
This is one of those things that sounds simple until you actually build it.
The app can't just sit there waiting for a background check to finish. It has to work around the fact that the answer might come minutes or hours later.
And because this is a childcare marketplace, screening isn't just another feature.
It's part of what makes the product usable in the first place.
Why I didn't rush the build
There was a point where I could have started producing screens immediately.
The previous teams had done exactly that.
Instead, I spent the time getting the rules answered first.
From the outside, that can look like nothing is happening.
A client sees a developer working for weeks without a long list of new screens and naturally starts wondering what they're paying for.
But starting early would have just moved the uncertainty into the code.
I'd rather spend two weeks finding out what the product should do than spend two months building the wrong version of it.
Where it is now
The app is live and still running, with caregivers onboarded and marketing underway.
What the client said
"He had a total and complete understanding of the project. In fact he brought ideas that made the app stand out."
This project is a good example of the kind of work I like doing.
The obvious job was to build an app.
The actual job was figuring out what the app was supposed to do before writing the code.
Two teams had already built screens. What was missing was someone willing to stop and ask a simple question:
"What should actually happen here?"
Once we had those answers, I could build the thing properly.