Last week I wrote about building a cold-call tool to sell websites to contractors. This week I built the thing the cold calls are actually selling: missed-call text back. A contractor on a roof cannot answer his phone. The caller hangs up, dials the next name on Google, and a $5,000 job disappears. My system forwards the call to his real cell, and if he cannot pick up, it texts the caller back within about five seconds so the lead holds still.
By this afternoon the backend had 66 passing tests. Not just unit tests. Integration tests that run the real webhook routes and real SQL against a real in-process Postgres, with the production signature verification in the loop. The kind of suite that earns you some confidence.
Then I bought a phone number, pointed it at production, and called it from a second phone.
Thirty minutes of real calls found three bugs that would have silently lost customers. Not crashed. Not errored. Lost leads without a trace, which for this product is the one unforgivable failure.
Bug one: the most common missed call produced no event at all
The system learns a call was missed from a callback the telephony provider sends after the forwarding attempt finishes. Every simulated test exercised that callback. Every scenario I could imagine flowed through it.
Here is what I could not imagine: when the caller hangs up while the phone is still ringing, the provider never sends that callback. Not a failure code. Nothing. The call just ends and you were not told. This is documented, standard, Twilio-compatible behavior that half the industry builds on. I had read the docs and still carried the assumption that call ends produce events.
Think about who hangs up while it is still ringing: someone who gave up after four rings. That is not an edge case. That is the missed call. The exact lead the product exists to catch was the one case where the system heard nothing.
The fix is a second, call-ended event that acts as a safety net. Any call that ends without a recorded outcome is treated as missed and gets the text.
Bug two: the fix raced itself
With two callbacks in play, my audit log showed something new: two send attempts for the same call, 123 milliseconds apart. The original callback and the safety net had both arrived, both checked the database, both concluded nobody had sent a text yet, and both sent one. A rate-limit rule happened to absorb it during my testing. A fresh caller would have gotten the same apology twice, which reads less like a helpful contractor and more like a broken robot.
The fix is boring and correct: classification became an atomic database claim. Whichever callback flips the call's outcome first is the only one allowed to send. Timing is not a defense. A row lock is.
Bug three: the mute button that never released
The system texts any given number at most once per hour, so a customer calling back three times does not get three apologies. The rule was implemented as "look up the last outbound message to this number." Reasonable. Except blocked attempts are also logged as outbound messages, for auditing. So every suppressed attempt refreshed the window, and a caller who kept calling back kept pushing their own unmute further away. Forever, if they were persistent. The politeness feature was eating the persistence of exactly the customers who wanted to buy something.
Now only messages that actually left the building count.
What the afternoon was worth
The suite is at 72 tests now and all three bugs are pinned under regression coverage. But none of the three were findable in simulation, and I want to be precise about why. The tests verified the system I designed. The phone calls verified the phone network that exists. Those are different objects, and the gap between them is exactly where products lose their users' trust.
The deeper protection is structural. This product's entire pitch to contractors is that it does not lose leads. So before any customer touches it, it runs on my own number, wired to my own cell, and I am customer zero. Every call to my business line goes through the same code path a client's customer would. Every bug it will ever have, I want it to have on me first.
The product is called Snapline. There will be more to say about it once the phone carriers finish their paperwork, which is its own story about why sending a text message as a business takes two hours of code and two weeks of compliance.
If your business runs on software that almost fits, and you are papering over the gap with spreadsheets and workarounds, that gap is what Neeka Studio builds for. The contractor version happens to involve phone calls. Yours probably involves something else.
