The Day a Thousand Properties Took Two Minutes

This is the latest in our running series on what building a small business with AI in the loop is actually like. Earlier ones covered why Google was ignoring our website, the time it nearly published our subscriber list, and the day it emailed the wrong Dan. This one is the most genuinely useful change we have seen yet, so it is worth being precise about what actually happened.

A thousand properties used to be something you scheduled. Last week it was something we talked through over a coffee.

What we set out to do

We run a SaaS platform, and like most SaaS platforms the slowest, most manual bit is onboarding a new client's data. Someone sends you a spreadsheet of their world, and your job is to get it into the system cleanly: matched to the right records, validated, deduplicated, with the messy rows flagged back to them so they can fix their end.

Two years ago that meant one of two things. Either a developer wrote a one-off import script, which goes the way these always go: write it, run it, watch it choke on a stray comma, fix it, run it again, repeat until it holds. Or a person sat there copying, checking and correcting by hand. Either way it was hours to a full day per client, and the moment the next client sent a slightly different format, you started over.

This time we did not write a script. We had a conversation.

What the AI actually got right

The unlock here is not "a chatbot that writes code." Plenty of tools do that and it is genuinely not the interesting part. The unlock is that this AI was connected to our real database. It was not guessing from a description of the data. It could see the data.

Here is what that bought us, concretely.

It worked against reality, not assumptions. When we designed the property import, it queried the database directly rather than taking our word for anything. It found roughly 1,009 jobs sitting across exactly 1,009 unique property-plus-type combinations, which told it a particular matching strategy was safe for this specific dataset. Not safe in theory. Safe for these rows.

It built the logic around what was genuinely there. It started with one matching approach, then worked through the real-world cases and pivoted to a reference-first match because the data told it to. The old approach was not thrown away, it was repurposed into a non-blocking "possible duplicate" flag. That is the kind of design decision we would normally expect from a developer who had lived with the data for a week.

It wrote its own tests. It generated the test files itself, an original CSV and a delta with deliberate changes baked in, so we could watch the system correctly spot 2 updates, 1 duplicate and 1 brand-new record. Made in seconds, not built by hand.

It verified at scale against a live environment. This is the part that sold us. It did not just claim the import worked. It built a 400-row bulk test, ran a 403-row re-upload against live staging, deliberately crossed the system's internal pagination boundary where these things usually break, and then asserted the result was exact down to the row. Every update, every duplicate, every new record accounted for, zero accidental duplicates.

It explained the failures in English. A real import rejected 20 rows. Instead of a stack trace, we got: "12 had a chase-letter date with no introduction date, 5 had dates out of order, 3 were missing a reference." That is not a database error dump. That is a summary we could forward straight to the client.

It even did forensic work. An engineer hit an "admin moved this job" warning, so the AI pulled that job's full history from production, confirmed nobody had moved or reassigned it, identified it as a stale-cache false alarm, traced it to the exact line of code, and proposed the fix.

Where it nearly led us astray

Now the part the series exists for, because a sanitised version of this post would be useless to you.

The same confidence that makes this AI fast makes it confidently wrong sometimes, and twice in this work it would have cost us real time if we had taken it at its word.

The first was during that bulk import. It got it into its head that the run had created mass duplicates and told us so, clearly and convincingly. If we had believed it, we would have spent the afternoon rolling back a release that was completely fine. What saved us was not the AI's reassurance. It was making it go and check. It queried the live data, found zero duplicates, and corrected its own assessment. The verification caught the AI, not the other way round.

The second was that "admin moved this job" warning. The forensic work it did was genuinely impressive, but its first instinct was to treat the warning as real and start designing a fix for a bug that did not exist. Only when it reconciled the hypothesis against the actual audit trail did the real answer (a stale cache) fall out. A first-draft fix for a phantom bug is exactly the sort of thing that ships when nobody insists on the evidence.

The lesson both times was the same. The value is not in trusting the AI. It is in the fact that it can check itself against real data, and that we make it. Take the verification away and what you have is a very fast, very articulate way to be wrong at scale. The honesty point matters as much here as it did when it tried to forecast our apps: the model is a brilliant collaborator and a poor authority.

Why this actually matters for a SaaS business

Step back from the property import and the shape of the thing changes.

The old model assumed a fixed ratio. So many engineers per feature, so many hours per client onboarding, so many days between "client asks for a change" and "it is live and tested." Context-aware AI rewrites that ratio. A data job that needed a developer and a day now turns round in an afternoon, tested, with the client's own issues explained back to them in plain English.

The bottleneck moves. It stops being "can we build it" and becomes "what should we build," which is exactly where you want your hardest question to sit. A lean team can take on data work that used to need more people, and move faster than the headcount suggests. The slow, manual, error-prone bit of running a SaaS, onboarding, starts turning into something fast, repeatable and increasingly self-service.

That is the bit small businesses should pay attention to. It is the same lesson we took from adding AI to Golf Handicapp: the wins come from pointing AI at a real, specific job inside your business, not from bolting a generic chatbot onto the side.

The honest caveats

Three things keep this credible rather than hype.

It is not autonomous. A human makes the calls and reviews everything. The AI is a fast, capable collaborator, not a replacement for judgment, and the two near-misses above are why.

Verification is the whole product. The value comes from checking against real data, every time, not from trusting the AI's word once.

And data protection is not optional. Connecting AI to live systems needs real care, especially in a regulated sector like housing. In practice the heavy lifting is done against test and staging data, and the AI reads patterns and error types rather than personal records.

What we would tell someone else

If you run a business with a slow, manual data job buried in it, the question worth asking is not "can AI write the script." It is "can we safely let AI see the real data, and will we hold it to checking its own work." Get those two right and a job you used to schedule becomes a conversation you have over a coffee.

If that sounds like a corner of your business, this is exactly the kind of work we do, so tell us about it or see what we have built. It is the most useful AI has been to us yet, and we are barely getting started.