DEV Community: Revenue Search

We Were Optimizing the Wrong Number in Our Scheduling System

Revenue Search — Mon, 21 Sep 2026 19:01:14 +0000

Last quarter I pulled the route data off a small service business I help run in Toronto. Twenty nine working days. Three thousand three hundred and fifty eight kilometres. That works out to about 115 km a day to complete roughly one and a half jobs.

Nobody had ever looked at that number, because nobody was measuring it. We were measuring jobs completed and revenue per job. Both were going up. The business looked healthy.

What we were actually running was a vehicle routing problem, and we were solving it greedily.

Greedy scheduling looks fine until it isn't

Every booking got placed at whatever time the customer asked for. First come, first served, no constraint on where the previous job was. On paper that is maximum customer satisfaction. In practice it meant a morning in Mississauga and an afternoon in Markham, with ninety minutes of highway in between that nobody is paying for.

The cost is invisible because it never appears as a line item. It shows up as fatigue, as a late arrival, as a third job that could not be booked because there was no room left in the day.

The constraint we added

One rule: a day gets one geographic cluster. If the first job is in Scarborough, every other job that day is in Scarborough.

That sounds obvious written down. It was not obvious while the calendar was filling itself. We had to turn down bookings we could technically have serviced, which felt like leaving money on the table right up until the day we fit three jobs into the hours that used to hold two.

Agincourt turned out to be the cleanest test case. It is dense, it is residential, the housing stock is consistent, and the drive between any two addresses inside it is under ten minutes. Once we started treating house cleaning in Agincourt as a single scheduling unit instead of a series of unrelated appointments, jobs per working day went up without anyone working longer hours.

What I would tell someone building the same system

Measure the gaps, not the tasks. Task duration is the number everyone instruments, because it is the easy one to instrument. The gap between tasks is where the capacity actually goes, and in a field service business that gap is measured in kilometres.

Cluster before you sequence. Sorting a day's stops by travel time is a much smaller optimization than deciding which stops belong in the same day at all. Get the partition right and the ordering barely matters.

Treat geography as a hard constraint, not a soft preference. Soft preferences lose every argument with a customer who wants Tuesday at nine. If the rule can bend, it will bend every time, and you end up back at greedy.

The frustrating part is that none of this needed software. We did not build a solver. We drew five circles on a map and refused to book outside the circle of the day. The whole fix was a constraint we had been unwilling to enforce, and the reason we had been unwilling to enforce it was that the dashboard we were watching could not see the cost.

What Cleaning a Converted Warehouse Taught Me About Where Problems Actually Accumulate

Revenue Search — Sun, 20 Sep 2026 16:19:05 +0000

I spent a weekend helping a friend clean out a hard loft in a converted industrial building. Exposed brick, concrete floors, twelve foot ceilings, the original ductwork still running across the room at head height and above. It is a beautiful space and she had been living in it for about a year.

She had been cleaning it constantly and could not work out why it never felt clean.

The problem was not where she was looking

Everything she could see and reach was spotless. Counters, floors, the kitchen, the bathroom. She had been doing that weekly and doing it well.

Ten feet up, the ductwork had a year of dust sitting on top of it in an even grey layer. Same on the sprinkler pipe, the conduit runs, and the tops of the original beams. From the floor you could not see any of it, because you were looking at those surfaces edge on. The only way to know was to get up there.

Then every so often the HVAC would kick on, or somebody would slam the door, and a bit of it would drop. She would clean the floor again. It would be dusty again in three days. She had concluded that the building was just dirty.

Why this stuck with me

The pattern is uncomfortably familiar if you work on systems for a living.

The stuff you can see gets attention because it is the stuff you can see. The dashboard you check is the dashboard you built, and it covers the things you already thought to instrument. Meanwhile the actual source of the recurring problem is sitting in a layer nobody looks at, quietly accumulating, and periodically dropping into the part you do monitor.

You end up cleaning the floor over and over and calling it maintenance.

What fixed it

Working top down. Poles, a ladder, and starting with everything above head height before touching anything below it. If you do it the other way round you clean the floor twice and you will not understand why.

That is apparently standard practice for anyone who does this professionally. When I looked into it afterwards I found a company that writes about deep cleaning in Riverside and specifically calls out the high dusting on exposed ductwork as the reason loft owners think their place is cursed. Not a complicated insight. Just one nobody had told her.

The transferable bit

When something keeps coming back after you fix it, the fix is probably not at the level you are working. Go up a layer. Look at the thing that has never been instrumented, never been logged, never been cleaned, because nobody could see it and therefore nobody thought about it.

Then work top down.

Her loft has been fine for six months.

Why Estimating a Deep Clean Is the Same Problem as Estimating Legacy Code

Revenue Search — Fri, 18 Sep 2026 20:53:12 +0000

I run operations for a cleaning company in Toronto, and the hardest part of the job is not the cleaning. It is the quoting.

Someone calls and says "four bedrooms, three baths, deep clean, how much." That is the entire spec. You have never seen the house. You cannot see the house. And you have to put a number on it that you will be held to.

If that feels familiar, it is because it is the same problem as being handed a repo you have never opened and asked how long the migration will take.

The variable that ruins every estimate is condition, not size

Square footage is the number everyone quotes on because it is the number everyone has. It is also the weakest predictor in the whole model.

Two identical houses, same floor plan, same street. One was cleaned every two weeks for six years. The other has not had a proper clean since the previous owners left. Same square footage. The second one takes twice as long, and almost all of the extra time lands in four places: the oven, the shower glass, the grout, and the window tracks.

Those four are not "more of the same work." They are a different category of work. Everything else scales with area. Those scale with neglect, and neglect is invisible from a phone call.

It is the difference between "this file is 4,000 lines" and "this file is 4,000 lines and has no tests." Line count told you nothing about the actual cost.

Older stock is the legacy codebase

We do a lot of work in neighbourhoods where the houses are eighty or ninety years old, and the pattern holds every time. Original hardwood, original tile, three generations of renovations layered on top of each other, and cleaning products from four different eras soaked into the same grout line.

Nothing about it is standard. The surfaces do not respond the way new-build surfaces respond, half the fixtures are discontinued, and there is always one room that somebody clearly did themselves in 1998. Anyone doing deep cleaning in Lawrence Park is estimating against unknowns the same way you estimate against a codebase with no documentation and one author who left in 2019.

What actually fixed our estimates

Three things, and none of them is "estimate better."

Ask the questions that predict condition, not size. When was it last professionally cleaned. Is it occupied or empty. Pets. That is three questions and they move the estimate more than square footage does.

Price the bands, not the point. We stopped giving single numbers for jobs we had not seen and started giving a range with the trigger written down: here is the price, here is what moves it, here is what it moves to. Customers do not hate ranges. They hate surprises at the end.

Make the unknown someone's job to check. The crew lead does a walkthrough before starting, not after. If the scope is wrong, we find out in minute five, not hour four.

That last one is the whole thing. You cannot estimate the unknown away. You can only shorten the distance between making the estimate and discovering it was wrong.

Why Grout Comes Back Grey No Matter How Hard You Scrub

Revenue Search — Tue, 15 Sep 2026 17:34:03 +0000

I spent a weekend scrubbing the bathroom in a Malvern rental before handing back the keys. Bleach, a stiff brush, three passes. The tile came up bright. The grout stayed grey.

I assumed I had not worked hard enough. That was the wrong conclusion, and it took a conversation with someone who does this for a living to understand why.

Grout is porous. Tile is not.

Glazed ceramic tile has a sealed surface. Dirt sits on top of it and a cloth takes it off. Cementitious grout is a different material entirely: it is full of tiny interconnected voids, and over years those voids fill with soap residue, body oil and mineral deposit from hard water.

Once dirt is inside a material, surface abrasion cannot reach it. You can scrub until your arm gives out and you are only ever cleaning the top layer of a substance that is dirty all the way through.

That is why the grout looked streaky rather than clean. I had lightened the outermost fraction of a millimetre and left everything underneath.

What actually works is chemistry and time

The fix is not more force. It is the right product left in contact long enough to dissolve what is in there, then a rinse to carry it out.

Three different problems, three different products:

Soap scum and body oil are alkaline-soluble. An alkaline degreaser, ten to fifteen minutes of dwell.
Hard water and mineral deposit need acid. A descaler, similar dwell, and never mixed with the above.
Mildew in the silicone is biological. Bleach gel does work here, but it needs to sit, and it will not fix discolouration that is actually mineral.

Notice that all three involve waiting. That is the part a weekend of scrubbing skips entirely. The brush is the last five percent of the job, not the first ninety.

Why this hits older housing hardest

Anything built in the GTA before roughly the mid-nineties is full of real grout lines. A condo finished in 2015 is mostly large-format tile, quartz and sealed surfaces, where almost everything genuinely does wipe off.

So two tenants can put in identical effort at move-out and get completely different results, and the one in the older unit concludes they are bad at cleaning. They are not. They are fighting a materials problem with a labour solution.

The people doing deep cleaning in Malvern and the surrounding older Scarborough housing stock told me the same thing in plainer words: they budget dwell time into the job, which is exactly the variable a DIY weekend has no way to price.

The practical version

If you are facing grout before a move-out inspection: put the product on first, go do the oven and the fridge for twenty minutes, then come back and brush. One pass with a wait beats four passes without one.

Effort was never the variable. Chemistry and patience were.

Backpressure, but for a buffet line: what catering 200 people taught me about flow control

Revenue Search — Mon, 14 Sep 2026 00:00:27 +0000

I spent a weekend helping run the food service for a 200 person event, and I came away thinking about it the way I think about systems under load.

The naive model is that throughput scales with the number of servers. Add more hands, feed more people. That holds right up until the line forms. Once demand outpaces the rate at which plates get filled, you get a queue, and the queue does not clear on its own. People wait, the food at the front gets cold, and the whole thing degrades. Sound familiar.

What actually fixed it was not more staff. It was backpressure. We staged the room so guests were released to the line in waves instead of all at once. The kitchen signalled when a tray was ready, and only then did the next group move. Throughput went up because we stopped overwhelming the bottleneck.

The second lesson was buffering. A good caterer pre plates the slow items and keeps a warm reserve, so a spike in arrivals draws down the buffer instead of stalling the line. The team we hired, a halal catering team in Toronto that does a lot of large events, did this without being asked. That is the difference between a crew that has served volume and one that is guessing.

The third was graceful degradation. When we ran low on one dish near the end, they did not stop the line. They substituted from the warm reserve and kept flow going, so nobody at the back felt the shortage. That is the buffet equivalent of serving a cached response instead of throwing an error.

None of this is in a systems textbook, but the physics rhymes. Whether it is requests or hungry people, the same rule holds: protect the bottleneck, buffer the spikes, and never let the queue win.

Serialization for lunch: what biryani taught me about state that survives transport

Revenue Search — Sat, 12 Sep 2026 15:54:47 +0000

Half of building anything distributed is accepting that your data has to survive a trip. It gets serialized, shoved through a channel that does not care about it, and has to arrive intact on the other end. I think about this every time I order biryani, because biryani is one of the few foods explicitly engineered for transport, and most kitchens get the engineering wrong.

Here is the failure mode. Biryani is rice and meat that finished cooking together under steam. The moment you seal it hot into a plastic container, it keeps steaming itself in transit, and by the time it reaches you the rice has gone from separate grains to a wet clump. That is not a cooking problem, it is a state-in-transit problem: the food kept mutating after it left the kitchen because nobody accounted for the channel.

The kitchens that actually solve it do two things any backend dev would recognize. They vent the container so it is not a sealed steam chamber, and they under-cook the rice slightly on the assumption that residual heat finishes the job on the drive, which is basically pre-computing for expected latency. A place doing biryani built for delivery in Toronto is really just designing for the transport layer instead of pretending it does not exist.

The general point, and the reason I keep finding these analogies in food: anything you hand off has to be built for the handoff, not just for the moment it leaves your hands. Serialize for the channel you actually have, not the one you wish you had.

What Recurring Cleaning Taught Me About SLOs

Revenue Search — Thu, 10 Sep 2026 22:21:15 +0000

A side project put me in charge of scheduling recurring work for physical spaces, and it quietly fixed how I think about service level objectives.

The setup: recurring house and office cleans, mostly every two weeks. The customer is not buying a spotless room. They are buying a guarantee that the room never gets past a certain point.

That distinction took me embarrassingly long to see, and it is the same one I had been fumbling at work for years.

Perfect is the wrong target

Early on we scoped every recurring visit like a full reset. Same work as a deep clean, every time. It was expensive, it ran long, and customers did not value it more. They rated it the same as the cheaper version.

What they noticed was variance. A visit that ran short. A week that got skipped. The bathroom being fine four times and then not fine once.

Availability targets work the same way. Nobody experiences 99.97 percent. They experience the one outage that landed during their demo. The number is a proxy for a much simpler question: can I stop thinking about this?

The threshold is the product

Once we scoped recurring visits as keep it above this line rather than make it perfect, three things fell out:

The work became predictable. Same rooms, same order, same duration. Predictable work can be staffed, priced and measured. Heroic work cannot.
We could tell when we were failing. A defined line means a missed line is visible. Without one, quality is just vibes and whoever complains loudest sets the standard.
We stopped over-delivering on things nobody checked. That capacity went into the two or three things every single customer looked at first.

That last one is the error budget idea wearing different clothes. If you are never missing your target, you are not being reliable, you are being wasteful. You have bought reliability nobody asked for with money and time that had somewhere better to go.

Maintenance is not remediation

The other thing that transferred cleanly: the gap between a maintained space and a neglected one is not linear. Skip two visits and the work does not double, it quadruples, because things bond, set and stain. Recovery costs far more than prevention, and the curve gets steeper the longer you wait.

Every engineer already knows this about dependencies, migrations and test suites. We just do not act on it, because prevention never produces a visible win and remediation always does.

When we finally wrote the standard down, it went into the scope of work for recurring cleaning in Toronto as a defined threshold with a defined cadence, which turned out to be the part clients compared vendors on.

The takeaway

An SLO is not a quality bar. It is a promise about consistency, and consistency is what people are actually buying. Aim at a line you can hold every time rather than a peak you can hit occasionally. The peak impresses nobody who has to live with the average.

What Running a Daycare Cleaning Contract Taught Me About Audit Logs

Revenue Search — Wed, 09 Sep 2026 17:27:21 +0000

I spend most of my time on systems, but a side project put me in front of a very different kind of compliance problem, and it changed how I think about logging.

The project was cleaning contracts for licensed childcare centres. Not the cleaning itself, the operations behind it. And the thing that surprised me was that the customer was almost never buying "clean." They were buying evidence.

Here is the shape of it. A licensed daycare gets inspected. The inspector does not watch you sanitize a bin of toys. They arrive weeks later and ask what happened on a Tuesday in March. If the only answer is "our cleaners came, they are good," that is not an answer. It is a claim with no backing store.

Any engineer will recognize the failure mode. The work was done and the work was untracked, which in a compliance context is the same as not done.

So the useful part of the contract was never the labour. It was the record. Every night: which surfaces, which product, which dilution, who signed off, timestamped, retrievable months later. That is an append-only audit log with a retention policy, described in different words.

A few things carried over almost exactly from software:

Granularity has a cost. Log every wipe of every surface and nobody reads it, the same way nobody reads a DEBUG-level firehose. Log only "cleaned the room" and it proves nothing. The useful level is the one an auditor would actually ask about, which took a few iterations to find.
Timestamps are the whole product. A record with no time on it cannot answer "what happened that Tuesday," and that is the only question anyone ever asks.
The log has to be written by the person doing the work, at the time of the work. Anything reconstructed afterward is a guess with good formatting.
Retention beats volume. One year of clean, boring, structured entries is worth more than three months of extremely detailed ones.

The other lesson was less comfortable. For a long time the operations side treated documentation as overhead on top of the real job. It is not overhead. In a regulated environment it is the job, and the physical work is the part that generates the record. Once you invert it that way, the process design gets a lot more obvious.

I see the same inversion go wrong in software constantly. Observability gets scoped as something you add after the feature ships, and then an incident arrives and the only honest answer is that nobody knows what the system did at 3am on the Tuesday in question.

The teams I have worked on that handled incidents well were not the ones with the cleverest architecture. They were the ones who could reconstruct a timeline without arguing about it. Same for the cleaning crews that keep their contracts. The ones who survive a licence review are not necessarily the most thorough. They are the ones who can show their work.

If you want to see how that gets packaged commercially, we ended up writing the documentation standard directly into the scope of work for daycare and childcare cleaning in Toronto, which turned out to be the part clients actually compared vendors on.

None of this is a novel insight. But it took a completely unrelated industry, with a regulator instead of a pager, to make me stop treating the log as a side effect of the work and start treating it as the deliverable.

What Deep-Cleaning a Neglected Space Taught Me About Paying Down Tech Debt

Revenue Search — Sun, 06 Sep 2026 13:38:13 +0000

Every codebase I have inherited has the same smell as a place that has not been properly cleaned in a year. Not the visible mess, that is easy. It is the stuff that accumulated slowly in the places nobody looks: the config nobody understands, the dead code behind the working code, the grime baked into the corners.

Regular cleaning is like linting and formatting. It keeps the surface tidy and it is cheap to run often. But it does nothing for the debt that has compounded underneath, because that debt is not on the surface, it is in the layers you have to deliberately pull apart to reach.

A deep clean is the refactor sprint. You pull the appliances out, you get behind and underneath, you strip the buildup off the fixtures that a wipe just slides over. It is slow, deliberate, and unglamorous, and it is the only thing that actually resets the baseline. After it, the cheap daily maintenance works again, because you are maintaining a clean state instead of fighting an accumulating one.

The mistake in both worlds is the same: trying to maintain your way out of a debt problem. You cannot lint away an architecture problem and you cannot wipe away a year of baked-on grime. You have to schedule the deep pass, do it properly once, and then let the cheap routine hold the line. I learned this the hard way and eventually just started booking a proper deep cleaning in Toronto on a schedule, the same way I now block time for debt paydown instead of pretending the daily grind will cover it.

The reframe that stuck: maintenance preserves a baseline, it does not raise one. If your baseline has drifted, no amount of routine gets it back. That is a deliberate, scheduled, deep-pass job, whether it is your code or your kitchen.

The made-to-order tax: a throughput vs quality tradeoff, told through kottu roti

Revenue Search — Sat, 05 Sep 2026 05:05:38 +0000

Every system that serves requests has to pick a point on the throughput-versus-quality curve, and food is no exception. I got thinking about this watching kottu roti get made, because it is one of the clearest real-world examples of a made-to-order system I can point to.

Kottu is chopped flatbread stir-fried on a hot griddle with egg, vegetables and meat. The whole appeal is that it comes off the griddle hot, with crisp edges and a bit of chew, and you cannot pre-batch it and hold it under a lamp because the texture collapses in minutes. So a kitchen serving kottu is effectively running synchronous, per-request processing: each order is cooked fresh, which caps throughput but keeps quality high. The failure mode of trying to "optimize" by batching is exactly the soggy, reheated version everyone has had once and never ordered again.

The tradeoff shows up on the client side too. Made-to-order means you wait, and it means ordering ahead helps, which is why a spot like a kitchen that makes kottu roti in Toronto to order on weekends will tell you to give it a little lead time rather than pretend it can be instant. That is not a limitation to engineer away; it is the constraint that guarantees the output is good.

The general lesson, and the reason I keep coming back to food as a systems metaphor: some quality properties are inherent to synchronous processing and cannot survive batching. Know which parts of your pipeline are kottu, and stop trying to cache them.

The planning fallacy, served buffet-style: why every headcount estimate is wrong

Revenue Search — Thu, 03 Sep 2026 16:38:00 +0000

I spent a weekend helping cater a party, and it turned into the clearest lesson in estimation I've had outside of a sprint retro. The host swore it was "about 40 people." Sixty-one showed up. If you've ever watched a two-week estimate quietly become five, you already know this story.

Everyone estimates the happy path

The host wasn't lying; they were doing what we all do. They pictured the core guest list — the people they'd definitely invite — and forgot the plus-ones, the "oh I told my cousin," and the coworkers who RSVP'd late. In software terms, they estimated the happy path and ignored edge cases, retries, and the integration nobody remembered. The optimism isn't a character flaw, it's how brains scope work.

Buffer the cheap things, forecast the expensive ones

The fix isn't "just estimate better" — humans are bad at this and always will be. It's structural. In a kitchen you over-provision the cheap stuff (rice, bread, salad) so running out is never the failure, and you forecast the costly stuff (protein) carefully because that's where waste hurts. Same as padding your cheap horizontal scaling while being disciplined about the expensive external calls.

Price the overage in from the start

The other trick is making the estimate error cheap to absorb. The caterer we used quoted per head with a clear rate, so when the number crept up the cost scaled predictably instead of blowing up — I later noticed they publish an affordable per-head model in Toronto for exactly this reason, so a client who guesses low doesn't get a nasty surprise. It's the same reason usage-based pricing and graceful backpressure beat a hard cap: the system bends instead of breaking when the inputs are bigger than anyone predicted.

None of this makes your estimates accurate. It makes being wrong survivable — which, for both dinner parties and software, is the only realistic goal. Assume the number is low, make the overage cheap, and protect the one or two things that actually hurt when they run out.

What move-out cleaning taught me about definition of done

Revenue Search — Sat, 29 Aug 2026 19:49:04 +0000

I run a cleaning company in the GTA, and the job that taught me the most about shipping quality work wasn't a complicated one. It was move-out cleans.

A move-out clean has the clearest acceptance test in the business. A landlord or property manager walks in with a checklist and either signs off the deposit or they don't. There is no "looks good to me." Either the oven passes or it doesn't. That external, binary sign-off changed how I think about the word "done."

When we started, "done" meant the place looked clean. That is the trap. Looking clean and passing an inspection are two different states, the same way code that runs on your laptop and code that passes CI are two different states. The gap is always in the places nobody looks until someone with a checklist does: inside the oven, the fridge seals, cabinet interiors, window tracks, the tops of the door frames.

So we treated it like a flaky test suite. We wrote the acceptance criteria down, made it identical every time, and stopped relying on judgment. Our move-out cleaning across the GTA now runs off a fixed checklist that mirrors what property managers actually inspect, not what feels thorough in the moment. When a manager flags something we missed, that item gets added to the list for every future job. The checklist is the regression suite.

A few things transferred surprisingly well from software:

A written definition of done beats "use your judgment" every time, especially with a rotating crew.
The expensive failures live at the boundaries: the edges, the seams, the surfaces you can't see from the middle of the room.
When a check fails in the field, you don't just fix that one instance. You add it to the list so it can never silently fail again.
A photo before handoff is just monitoring. You want to catch the problem before the customer does.

None of this is glamorous. But the boring, repeatable version is the one that gets the deposit back every single time, and "every time" is the only quality bar a customer actually cares about.