The Most Important Part of Our Website Wasn't Under Our Control
. Reading time: 4 minutes.How moving from a hosted form provider to Azure Static Web Apps gave us more control over a business-critical system.
The most important page on this website isn’t the homepage, the services page or the blog, it’s the contact form, that’s where enquiries turn into conversations and conversations turn into work, and for two years ours ran on infrastructure we didn’t control. I moved it in-house in July, and nothing changed for anyone filling it in, everything changed behind the scenes instead.
Whose server is your form actually on
A hosted form service is an easy win, you drop a snippet into the page, point it at your email, and you’re done, ten minutes tops. We used one for a couple of years and it did the job, no complaints from me.
But every enquiry went through their server, and the email arrived from their sending domain instead of ours, which is fine until it isn’t. A pricing tier changes, a free service gets retired, or it just has a bad day, and it’s sitting on the one page where new business comes in with none of it under my control.
None of those things are likely tomorrow, but they happen every day somewhere, and when a tool sits directly between a potential customer and the business, even a minor disruption can mean missed opportunities. For a company whose whole pitch is helping people own their own tech, that was a slightly odd thing to have been running.
How it works now
The form posts to /api/contact now, a small function that ships with the rest of the site. Azure Static Web Apps has a built-in back end, so anything I put in the api folder gets deployed alongside the site with no separate server to set up or pay for. That is probably my favourite thing about it, the back end comes free with the hosting.
The function sends the email through Azure Communication Services from our own domain, and sets the reply address to whoever filled the form in, so when I hit reply I am writing straight back to them. There is a honeypot field to deal with the bots (they fill in every box they can find, so anything that fills that one in goes quietly in the bin).
It wasn’t a big piece of engineering either, the whole replacement landed in a single commit, the function itself is under 150 lines of code, and it runs within our existing hosting. At the volume a form like this sees, it currently costs us nothing to operate.
None of this makes the form better for the person filling it in, they probably wouldn’t notice the change, and that’s fine, the benefit is that we control a business-critical process instead of renting it from someone else. If an email fails we can investigate it, if we need extra validation we can add it, and if we want enquiries pushed into a CRM later we can extend the same function ourselves, and nobody can pull it out from under us.
What I would check on your own setup
Our form is a small example, most businesses run on a stack of these little tools, the one that sends the invoices, the one that books the appointments, the rule that decides where an email ends up. A lot of them are free tiers or someone else’s platform, and most of the time that’s completely fine.
I am not saying rip it all out (that would be daft, and expensive, and half of it is doing its job perfectly well). But I think it helps to know which of those tools you could actually move or fix if you had to, and which ones you just have to hope keep working, especially the ones sitting on the path to getting paid or getting new work.
We certainly don’t own every system we use, and I don’t think most businesses should, the important thing is knowing where the weak spots are. If a critical tool vanished tomorrow, would you have options, or would the business stop with it? That’s the sort of question we help clients work through.