There's a particular kind of Saturday morning that every solo developer knows well. You wake up, make a coffee, open your laptop to check something quick — and three hours later you're seventeen tabs deep into a debugging session with no memory of how you got there. That's roughly how this weekend started for Mathew, Team-Connect's lead (and only) developer.
What was supposed to be a quick look at an error log turned into a 48-hour development sprint that touched virtually every layer of the platform — from the Twilio webhook handlers that route customer calls, to the Cloud Functions that power the AI receptionist, to the static HTML pages that make up the public-facing website. By Sunday evening, Team-Connect was measurably faster, significantly more reliable, and had an entirely new Help Center that didn't exist on Friday.
This post is the full, unfiltered breakdown of everything that happened. Not the polished marketing version — the actual technical story of what broke, what was slow, what was annoying, and what got done about it.
Why Weekend Sprints Happen (And Why They Matter)
When you're running a platform that handles live phone calls for thousands of UK businesses, there's no such thing as "we'll get to it next quarter." A Twilio error that causes 1 in 50 calls to fail isn't a backlog item — it's a business owner somewhere in Manchester whose customer just heard dead air instead of a greeting. A slow-loading pricing page isn't a PageSpeed vanity metric — it's a potential signup who clicked away before the content rendered.
The reality of running a product like Team-Connect as a solo developer is that weekdays are consumed by feature work, customer support, and keeping the lights on. The deep, focused debugging sessions — the ones where you trace a problem from a vague error message all the way down to a single misplaced parameter buried in a webhook handler — those need uninterrupted time. Weekends provide that.
This particular weekend had been building for a while. The error logs had been accumulating a handful of recurring issues that weren't catastrophic individually but were collectively creating friction. A Twilio error here, a slow function cold start there, a PageSpeed score that had crept down after a few rapid feature deployments. Nothing was on fire, but the platform wasn't as tight as it should have been. Saturday morning, Mathew decided to fix all of it at once.
What followed was the kind of focused, relentless productivity that only happens when someone genuinely cares about the product they've built. No standups. No sprint planning meetings. No Jira tickets to file before you're allowed to start working. Just a developer who knows every line of his codebase sitting down with a cup of coffee and a list of things that need to be better — and not stopping until they are.
The Hit List: What Needed Fixing
Before writing a single line of code, the first job was triage. Mathew pulled error logs from the past two weeks, cross-referenced them with customer support tickets, ran PageSpeed audits on every public page, and built a prioritised list of everything that needed attention. The list was longer than expected.
The critical fixes clustered around two areas: Twilio call handling (where specific error codes were causing intermittent call failures) and the outbound desktop calling flow (where a subtle case-sensitivity bug was preventing calls from connecting for a subset of users). The performance improvements were spread across Cloud Functions, static page assets, and the voice AI server. And the new feature — the Help Center — was something that had been on the roadmap for weeks but never found its way into the weekday schedule.
Twilio Call Handling: Killing Errors 13699 and 21626
These two Twilio errors had been appearing intermittently in the logs for days, and tracking them down required understanding the full call flow from the moment a customer dials a Team-Connect number to the moment the AI receptionist picks up.
Twilio error 13699 fires when a TwiML response includes an invalid trim attribute on a <Record> or <Gather> verb. The root cause was in twilio-handlers.js — a trim parameter was being set dynamically based on business configuration, but certain edge cases produced values that Twilio's API rejected. The fix involved validating the trim value against Twilio's accepted options before including it in the response, with a sensible fallback default.
Error 21626 was trickier. This fires when the statusCallbackEvent parameter contains values that Twilio doesn't recognise. The issue was that the array of callback events included a value that had been deprecated in a recent Twilio API update — it was valid when the code was originally written but had since been removed. The fix was straightforward once identified: update the event list to match the current API specification and add validation to catch any future deprecations.
Both fixes were deployed to production and verified with live test calls within an hour of being identified. The error rate for call connection dropped to zero immediately. Every call that had previously triggered a 13699 or 21626 now connected cleanly on the first attempt.
Cloud Function Optimisations: Faster, Leaner, Cheaper
Team-Connect runs on Firebase Cloud Functions (v2, Node.js 20), and over time the functions had accumulated some inefficiencies. Cold starts were taking longer than they should, memory allocation was higher than necessary on several functions, and a few hot paths were doing redundant Firestore reads that could be cached or eliminated entirely.
Several Cloud Functions were importing modules at the top level that they only needed conditionally. Moving these to dynamic imports — loading them only when the specific code path that needed them was triggered — reduced cold start times by an average of 300ms across the most frequently invoked functions. On a platform that processes real-time phone calls, 300ms matters.
The default memory allocation had been set to 512MB across all functions regardless of actual usage. Profiling revealed that most functions peaked at under 200MB. Right-sizing the memory allocation to match actual usage — 256MB for lightweight functions, 512MB only for the AI-heavy ones — reduced overall memory consumption by 25% and cut Cloud Function costs proportionally.
The twilioStatusCallback handler was performing a full document read on every status update, even for statuses that didn't require account data. Adding an early return for non-actionable statuses (like ringing) eliminated thousands of unnecessary Firestore reads per day. The call minute deduction flow — which only needs to run on completed status — was refactored to be the only path that touches the database.
The cumulative effect of these changes was significant. Functions responded faster, used less memory, generated fewer Firestore reads, and cost less to run. Not glamorous work, but the kind of optimisation that compounds over time — especially as call volumes grow.
Voice AI Audio Quality: Getting the Sound Right
The voice AI server — the Cloud Run service that orchestrates Deepgram (speech-to-text), Claude (intelligence), and ElevenLabs (text-to-speech) — had been exhibiting occasional audio artefacts. Callers would sometimes hear a brief pop or click at the start of the AI's response, and in rare cases the first syllable would be clipped.
The root cause turned out to be a combination of two issues. First, the audio encoding wasn't consistently using mu-law (the encoding standard for telephony audio) — some responses were being sent in a different format that required re-encoding on the fly, introducing latency and artefacts. Second, the silence padding between the end of the caller's speech and the start of the AI's response was too short, causing the leading edge of the audio to collide with the tail of the incoming stream.
The fix involved standardising the encoding pipeline to mu-law throughout, adding appropriate silence padding at the start of every AI response, and improving the binary vs JSON frame detection logic that determines how incoming WebSocket messages are processed. Post-fix test calls showed clean, artefact-free audio with natural-sounding transitions between caller and AI speech.
The frame detection improvement deserves a quick mention because it was a subtle but important change. The voice server communicates over WebSocket, and incoming messages can be either binary audio data or JSON control messages. The previous logic was using a heuristic to distinguish between the two that occasionally misidentified a JSON frame as binary data, causing the audio pipeline to try to decode text as sound — which produced exactly the kind of pops and clicks callers were hearing. The updated logic checks the WebSocket frame type explicitly, eliminating the guesswork entirely.
Why audio quality matters this much: If a caller hears a pop, a click, or a clipped syllable, they immediately suspect they're talking to a machine. The illusion of natural conversation depends on flawless audio — not just accurate words, but clean, properly-timed delivery with no technical artefacts. Getting this right is the difference between callers thinking they're speaking to a real receptionist and callers hanging up because "the line sounds weird."
PageSpeed Blitz: 40% Faster Load Times
Over the previous few weeks, several rapid feature deployments had introduced performance regressions on the public-facing pages. The features page and pricing page had accumulated bloat — oversized images, unused JavaScript, render-blocking resources — that dragged their PageSpeed scores down.
Mathew ran a systematic audit across every public page and attacked the biggest offenders:
The Team-Connect logo was being served at its full resolution on every page, even though the displayed size never exceeded 40px height. Resizing and compressing the logo asset, plus converting to WebP where supported, eliminated unnecessary bytes on every single page load. Similar treatment was applied to hero images, partner logos, and social media icons across the site.
The pricing page was loading the full Firebase SDK — authentication, Firestore, analytics — even though it's a completely static page that doesn't need any of it. Removing the unused SDK import from static pages shaved over 200KB from the initial payload and eliminated a render-blocking script that was adding 800ms to the time-to-interactive.
Static assets — fonts, images, CSS, JavaScript — weren't being cached effectively because the cache headers in firebase.json hadn't been configured for the newer asset paths. Adding proper Cache-Control headers with long max-age values for versioned assets meant returning visitors loaded pages almost instantly from cache rather than re-downloading everything.
The combined effect was dramatic. Average page load time across the public site dropped from approximately 3.2 seconds to 1.9 seconds — a 40% improvement. PageSpeed Insights scores jumped by 15–25 points across the board. The pricing page, which had been the worst offender, went from a score of 62 to 91 on mobile.
Desktop Calling: The Case-Sensitivity Bug
This one had been particularly annoying because it was intermittent and the error messages were misleading. Some users reported that outbound calls from the web dashboard would fail silently — the interface would show "connecting" but the call would never go through. Others had no issues at all.
The twilioDesktopVoice Cloud Function was expecting a parameter called To (capital T) from the frontend, but some code paths were sending to (lowercase). JavaScript object property access is case-sensitive, so req.body.To would return undefined when the frontend sent to, causing the function to silently fail without making the call. The fix normalised the parameter extraction to check for both cases, ensuring consistency regardless of how the frontend formatted the request.
A one-line bug that took two hours to find. The classic ratio. But once fixed, desktop outbound calling worked reliably for every user, every time — which is exactly how it should have been from the start.
Experience the Improved Platform
Every fix in this post is live right now. Try Team-Connect's faster, more reliable AI phone system.
The Help Center: Built From Scratch in a Day
Somewhere between the Twilio fixes and the PageSpeed audit — around Saturday afternoon — Mathew decided that the platform needed a proper Help Center. Team-Connect had documentation scattered across tooltips, onboarding modals, and support emails, but there was no single, comprehensive place where a user could go to understand every feature, every setting, and every workflow.
By Sunday evening, there was. The Help Center launched with guided assistance for every section of the Team-Connect dashboard, covering account setup, phone number management, AI receptionist configuration, call flow customisation, billing and plan management, SMS and email marketing features, and advanced settings.
Each section includes step-by-step walkthroughs written in plain English — not developer documentation, but genuinely helpful guidance written for business owners who want to set something up and get back to running their business. Interactive elements highlight exactly where to click. Common questions are answered inline. And the whole thing is searchable, so users can type what they're trying to do and land directly on the relevant guide.
The AI receptionist configuration guide alone runs to over 2,000 words, covering everything from setting your business greeting and operating hours to configuring industry-specific responses and managing the knowledge base that the AI draws on during calls. Previously, users had to figure most of this out through experimentation or by emailing support. Now every option is documented with context on when and why you'd use it.
The call flow section walks through the entire journey of a customer call — from the moment the phone rings to the AI handoff to the transcript delivery — with annotated diagrams showing what happens at each step and where the user's configuration choices affect the experience. Understanding this flow is fundamental to getting the most out of the platform, and having it documented properly means new users can grasp the full picture in five minutes instead of discovering features piecemeal over weeks.
Building it in a single afternoon wasn't exactly planned, but it's the kind of feature that improves every interaction a customer has with the platform from that point forward. Every support ticket that a good help article prevents is time saved for both the customer and the team.
The Full Weekend Timeline
The Results: Before and After
Here's the tangible impact of the weekend's work, measured against where things stood on Friday:
Call connection reliability went from approximately 97.8% to 99.9%. Page load times dropped from 3.2s average to 1.9s. Cloud Function costs decreased measurably. Voice AI audio quality improved from "good with occasional glitches" to "consistently clean." Desktop outbound calling works for every user without exception. And every customer now has access to a comprehensive Help Center that makes the platform easier to use from day one.
But the numbers only tell part of the story. The qualitative improvements matter just as much. Customers who had occasionally experienced a failed call connection — and who may have lost trust in the platform as a result — now get flawless call routing every single time. Business owners who were struggling to configure their AI receptionist now have a detailed guide walking them through every option. Users who'd reported intermittent issues with desktop calling can now make outbound calls with complete confidence.
These are the improvements that don't show up in a feature announcement but make the difference between a product that people tolerate and a product that people trust. Reliability is invisible when it's working. You only notice it when it's not. After this weekend, there's a lot less to notice.
None of these changes required downtime. Every fix was deployed incrementally using targeted Firebase CLI commands — individual functions redeployed, individual hosting files updated — with live verification after each deployment. Customers experienced the improvements without experiencing any interruption. That's the advantage of a deployment strategy built around atomic, incremental changes rather than big-bang releases: you can ship fixes continuously throughout a weekend without anyone's service being affected for even a second.
The bigger picture: This is what building a platform as a solo developer looks like. There's no QA team to catch the edge cases. No SRE team monitoring the dashboards. No separate frontend and backend squads splitting the workload. It's one person who knows every line of code, every configuration file, and every integration point — and who cares enough about the product to spend their weekend making it better. That's not a limitation. For a platform at Team-Connect's stage, it's a superpower.
What's Next
The weekend sprint cleared the backlog of accumulated technical debt, but it also surfaced opportunities for bigger improvements. The Cloud Function optimisation work highlighted potential for a broader architectural review of how call state is managed across Firestore. The PageSpeed audit revealed patterns that could be systematised into a build-time optimisation pipeline. And the Help Center's positive reception suggests that investing more in self-service documentation will reduce support load and improve customer satisfaction simultaneously.
On the telephony side, the Twilio fixes opened the door to exploring Telnyx as a parallel provider. Running dual telephony providers gives the platform redundancy — if one provider experiences an outage, calls can route through the other without any disruption for customers. The groundwork for this was already in the codebase as a provider flag in Firestore, and the weekend's cleanup of the Twilio handlers makes the integration point cleaner for when Telnyx handling is wired up.
The voice AI improvements also set the stage for the next wave of capability work. With the audio encoding pipeline now standardised and the WebSocket frame handling tightened up, the team can focus on higher-level improvements — things like more natural turn-taking in conversations, industry-specific vocabularies for the speech recognition, and smarter handoff logic when the AI encounters a question it can't confidently answer.
For now, though, the platform is in the best shape it's been in months. Every call connects. Every page loads fast. Every function runs lean. And when Monday morning arrives and thousands of UK businesses start their working week, Team-Connect will be ready — faster, more reliable, and better documented than it was on Friday.
That's not a bad weekend's work.
Ready to Try the Improved Platform?
Join 10,000+ UK businesses using Team-Connect. Set up in 5 minutes, plans from £9.99/month, no contracts.