

Of every request that reaches me, this one arrives most often, and it almost never arrives in technical language. It sounds like this: we are getting a lot of sign-ups, and we are tired of digging through email to find them. Can we just get them into a spreadsheet?
It is a completely reasonable request. It is also the request that most often hides a real business decision, because the honest answer is rarely a simple yes.
I worked through exactly this recently for Seminole Theatre, and that project is a useful window into what is possible now, what it actually costs, and which parts still require a person.
Their team was receiving sign-ups for three separate things: interest in the youth conservatory program, venue rental inquiries, and birthday party bookings. Each one arrived as its own email notification. The information was all there. It was simply scattered through an inbox, one message at a time, with no way to see how many had come in this month or which ones had already been answered.
Nobody was losing business yet. Everybody was spending time they did not need to spend, and a busy season would have made that worse.
What they asked for was a spreadsheet. What they actually needed was one place where the whole team could see every inquiry, newest first, with room to track who had followed up.
The first thing I do with a request like this is find out where the information actually lives. That step sounds unnecessary. It is usually where the surprises are.
In this case the three streams were not three forms in one system. Two were built with the site's form plugin. The third, the birthday party intake, was a custom form written specifically for that page, storing its information somewhere else entirely in a completely different structure. Nothing in the site's admin screens made that obvious.
The three streams also collect completely different information. A conservatory sign-up captures a parent, a child, an age, and areas of interest. A venue rental inquiry captures an organization, an event type, a preferred date, and a guest count. A birthday booking captures a party date, a package, and a theme. There is no single sensible way to stack those on top of each other in one list.
So the real request was not one connection. It was three connections into one destination, and it had to stay readable for people who are never going to think about any of this.
The subscribe path is a monthly automation service that watches for form submissions and copies them into a spreadsheet. It is quick to set up and requires no code. It also bills by volume, usually needs a paid step for each additional form, and routes your information through another company on its way from your website to your spreadsheet. When the information includes children's names and ages and parents' phone numbers, that last detail stops being a technical footnote.
The build path means a small amount of custom code that belongs to the business. No monthly fee, no per-submission pricing, and the information travels from the website to the spreadsheet without a middleman. The traditional cost of that path was developer hours, which is precisely why so many small businesses chose the subscription and lived with its limits.
Seminole Theatre is on a support and maintenance plan with us, and that changes this calculation more than most people expect.
A custom piece is only a liability when nobody is going to look after it. If the person who wrote it disappears, a small tool becomes a small mystery, and eventually a small emergency. Inside an ongoing relationship the opposite is true. The code can evolve as the client's needs change. A fourth form next year is an adjustment rather than a new subscription tier. When something breaks, there is a known place to go.
If you take one thing from this article, take that. Build or subscribe is not really a question about code. It is a question about ownership and attention over time.
Here is the honest version, because the overstated version is already everywhere.
AI did not decide what to build. It did not know the birthday form existed until we went looking for it. It did not decide how the information should be protected, or what counted as finished. What it did was compress the implementation from what would traditionally have been several days of developer work into a single working session.
That shift is not cosmetic. It moves the break-even point. Work that used to be too small to justify custom code, which is exactly the category this request falls into, is now frequently cheaper to build properly than to rent indefinitely.
I have been automating business processes for more than 30 years, and the thing that changed is not the ambition. It is the price of the small stuff.
Not a blueprint, but an honest inventory, because the request sounds like one step and never is.
Three streams, two storage systems, one of which was invisible from the normal admin screens. Getting this wrong at the start would have produced a spreadsheet that quietly missed an entire category of inquiry, which is worse than no spreadsheet at all.
The website runs on shared hosting. I deliberately kept every credential off that server and designed the connection so the site can send information to the spreadsheet without holding keys that could be abused if the hosting account were ever compromised. That was a security decision made before any code was written.
This is what separates a demonstration from something a team can actually use. Staff sort spreadsheets. They filter them, add columns, type notes, and occasionally delete a row by accident. A connection that assumes row three is always row three will start writing information into the wrong person's record the first time somebody sorts by date. This one identifies every record by a permanent identifier and finds every column by its heading, so ordinary human behavior cannot corrupt it.
Two columns on the right of every tab belong to staff: a status and a notes field. The automation never writes to them, and because records are matched by identity rather than position, a note stays attached to the right person no matter how the sheet is sorted. A tool that cannot be annotated by the people using it gets abandoned.
A spreadsheet that starts empty is not useful on day one. Every prior submission was loaded before handover, so the team opened a complete record rather than a promise that future ones would appear.
Services have outages. The website remains the master record, and a separate recovery process can rebuild the spreadsheet at any time without creating duplicates. Designing for the bad day is most of the difference between something that works and something that can be trusted.
This is the part nobody advertises. The logic was the quick piece. Getting two large platforms to speak to each other was not.
That is the real texture of integration work, and it is why an honest answer to how long will this take is a range rather than a number. The value of an experienced hand here is not typing speed. It is knowing that a success can look exactly like a failure, and checking the result instead of believing the error message.
If you are weighing the same decision, a few questions usually settle it.
One spreadsheet. A tab for each program, every prior sign-up already in place, newest at the top, and new ones arriving on their own within seconds of somebody pressing submit on the website. A summary tab shows how many have come in for each program and when the most recent one arrived. Staff can sort, filter, and annotate without breaking anything.
Nobody on that team needs to know any of what this article describes. That is the point. The measure of this kind of work is that the people using it stop thinking about it.
Three streams, one destination
No credentials on the website
Sorting and notes cannot break it
Rebuildable without duplicates
Often you can, and if a manual export once a month solves your problem, that is the right answer. Exports break down when several different forms need to land in one place, when more than one person needs the current picture, or when the information has to be available without somebody remembering to produce it.
For one simple form, usually yes. The math turns with volume, with the number of forms, and with time. A monthly fee continues for as long as the business does, while a build is paid once and then maintained. Ask how the price behaves in year three rather than in month one.
It should not, and if it does, it was built carelessly. A well built connection identifies each record by a permanent identifier rather than by its position on the page. Sorting, filtering, and adding notes should all be safe. Ask this question specifically before anyone builds anything for you.
The submission should still be saved on your website, which stays the master record, and the spreadsheet should be repairable afterward without creating duplicates. If the only copy of an inquiry lives in the spreadsheet, the design has a hole in it.
That depends entirely on how the spreadsheet is shared. A link that grants editing to anyone who receives it is a different risk from access granted to named people. My practice is to tell a client plainly what a given sharing choice exposes and to build sensibly for the choice they make. Sharing settings are a business decision, not a technical detail.
In principle yes, but the effort varies considerably. Forms built with a common plugin are the straightforward case. Custom forms, older sites, and anything storing information in an unusual way take longer, which is why an honest estimate starts with looking rather than quoting.
The working logic can come together quickly now. The connection between platforms is what consumes the time, and it is genuinely hard to predict, because failures in that layer are frequently misleading. Expect a range, and expect the final stretch to be verification rather than construction.
You do not need one to have something built. You need one for the thing to stay valuable. Custom pieces reward ongoing ownership and punish neglect, which is the whole reason the build or subscribe question is really a question about who is minding it next year.
A small business asked for something reasonable and specific. Meeting it properly required understanding three different systems, making a security decision before writing anything, designing around how people really behave in spreadsheets, loading the history, planning for the bad day, and then out-waiting an integration that disguised its own successes as errors.
AI made that affordable at a size where it previously was not. It did not make the judgment unnecessary. Faster building with the thinking kept in place is what has actually changed, and it means the answer to to build or not to build now lands on build far more often than it used to.
AI did not remove the decision.
It lowered the cost of acting on it. The questions worth asking about your own business are the same ones I would have asked 20 years ago.
You do not need to know how any of this is built before starting the conversation. Start by naming the information you collect, where it currently lands, and who has to touch it before it becomes useful.
Released Solutions can evaluate the process, tell you honestly whether building or subscribing makes more sense for your situation, and maintain whatever we build so it stays valuable.
Kenneth Durrum is the founder of Released Solutions, where he helps small businesses connect their websites, data, and daily operations so the information they collect ends up where the work actually happens.
