We built a homebuilder a scheduling assistant that texts their buyers and offers times their staff are free, then puts the appointment on the right calendar. The buyer never clicks a link or makes an account. Just over two years ago I would have estimated $200,000 to build it. I think that estimate would have been honest at the time, which is the part I keep chewing on.
Most companies should just use Calendly
I want to say this before I describe what we built, because the rest of this post is going to read like an argument for custom software and it mostly isn’t one.
If you need people to book time with you, buy the thing. Calendly works. Somebody else already spent years finding the edge cases, and they maintain it on their dime instead of yours. I’ve talked clients out of builds like this more than once, and I’d do it again for most of the people who ask. The honest default is that you’re better off with software you rent.
This client was the exception, and the reason is boring. Their scheduling runs through several departments with different rules, hanging off a back office that already knows which lot the buyer is on and which stage of the build they’re in. A booking tool that can’t see any of that just moves the coordination somewhere else.
What it does
The buyer gets a text in her messages app: “It’s time to schedule your design studio appointment. Want to find a time that works for you?”
She replies the way a person replies. “I need an appointment for Thursday afternoon.” The assistant comes back with four open times, numbered. She types “4”. She’s booked, and the appointment is on the designer’s calendar before she’s put her phone down.
She never left her messages, and there was no link in the thread to leave them for. The whole interface is one number.
Behind that are five staff calendars across design, finance, construction, and sales, holding the stuff a homebuilder’s week is made of: selections, underwriting, a rate call, a site walk, a framing inspection, lot 14.
The AI never picks the time
I’d defend this decision harder than anything else in the build, and it’s what makes the demo less impressive than it looks.
Availability is calculated. We pull calendar state from Outlook through Microsoft Graph, then work out valid options from working hours and existing events, with the buffer each department wants around an appointment. That math is deterministic. Same inputs, same answer, every time.
The model only gets handed the times that logic has already confirmed. It reads “Thursday afternoon” and turns it into a filter. It writes the confirmation sentence. It can’t produce 2:00 PM on its own, because it never has a list containing 2:00 PM unless the scheduler put it there.
That’s a capability we gave up. A model reasoning freely over a calendar could handle stranger requests than ours can. But a scheduling assistant that hallucinates one appointment has, in that moment, become worse than no scheduling assistant, and there’s no amount of good behavior on every other booking that buys that back.
Two people, one slot
Two buyers can want the same Thursday at 2:00. The system won’t hand it to both of them.
Preventing that is dull engineering, and the kind of thing that embarrasses you in week one if you skip it. It’s also exactly what you inherit for free when you rent a booking tool.
The features we didn’t build
I’d have underrated this a few years ago. A booking tool sold to everybody has to do what everybody needs, so most of what it does isn’t what you need: event types, availability rules, buffer settings, routing forms. Somebody on your team owns all of it, and keeping it true is a standing job nobody put on their calendar.
Theirs does one thing. There are no event types to configure, because the kinds of appointment are the ones the business already has. The availability rules never fall out of sync either, because they live in the back office and the scheduler reads them there. When a designer’s hours change, they change once, in the system that already owned her hours. The assistant is right the next time somebody texts. Nobody administers it.
The same goes for what it already knows. It has the buyer’s lot and the stage her build is at, so it doesn’t open by asking her to pick a category and fill in a form. A general tool has to ask, because it can’t know.
To be fair to the general tool, that overhead is the right trade for most companies. You carry settings you’ll never touch, and in exchange you never think about any of it and somebody else fixes it at 2am. I just think the number of businesses on the wrong side of that trade is bigger than it was.
About the $200,000
I’ve been estimating software projects since Zarin and I started HQ in 2012, and it’s one of the few things I’ll say I’m actually good at. Two years ago this is a multi-month build with a full team on it: the Graph integration, the availability engine, the conversational layer, the admin side, all of it. Two hundred thousand dollars was not a padded number.
We built it for a fraction of that. My assumption is that most of the difference is our own tooling rather than anything clever about this particular product, and I could be wrong about the split. What I’m confident about is the direction. The line between “we should just buy something” and “we should build exactly what we want” moved, and it moved far enough that projects I would have refused to quote in 2024 are now reasonable to bring up in a first meeting.
Which is a strange thing to write in a post that opens by telling you to buy Calendly. Both are true. The default is still to rent. The exceptions just got a lot cheaper, and there are more of them than there were.
What she saw
The buyer who booked that Thursday appointment has no idea any of this exists. She got a text, typed a 4, and showed up.
Everything above is us trying to make sure the number she typed was real. If you’re weighing a build like this against something off the shelf, we’re happy to talk it through, including the version where we tell you not to.
