Ahead of the October 15 filing deadline, some of our most demanding full-year time reports were taking more than a minute to load. Our engineering team rebuilt the underlying data model, bringing those reports down to under a second, an improvement of up to 130 times.
That change wouldn’t necessarily show up in an uptime percentage. But for an accounting firm trying to close out work before a filing deadline, it’s the kind of improvement that matters.
During peak season, dozens or hundreds of employees may be processing work, accessing client records, sending requests, recording time, and preparing invoices at once. A system can be technically online while a slow report, failed upload, or interrupted workflow prevents people from getting their work done. The consequences become more significant as the deadline approaches.
At Qount, preparing for those weeks means looking beyond overall availability. Much of the work happens before customers see an issue, and it involves decisions about performance, infrastructure, software changes, and how to respond when something unexpected occurs.
Preparing for Demand Before It Arrives
April and October are predictable peaks for the accounting profession. We know *when* activity is likely to increase, even if we can’t know exactly how much demand each part of the platform will experience.
That gives our engineering organization an opportunity to prepare deliberately. Starting in September, we ran a dedicated season-readiness program involving more than 70 pieces of work across eight engineering teams. The effort focused on functions firms depend on heavily near deadlines: tasks, client records, invoicing, time reporting, email processing, and the databases supporting those workflows.
Historical usage patterns help show where pressure is likely to build. Client portals may see more uploads and activity as deadlines approach. Inside firms, teams may be processing more work, sending more requests, and accessing client records more frequently. That information informs capacity planning, performance testing, and infrastructure decisions.
But preparing for additional traffic is only one part of the job. Database performance, background jobs, external integrations, and interactions between services can all affect the experience customers have. A platform can have sufficient computing capacity and still slow down because a single process becomes a bottleneck.
The time-reporting improvement illustrates the distinction. The problem was in the underlying data model. Rebuilding it reduced the load time of our most demanding full-year reports from more than a minute to under a second. Adding capacity alone isn’t a substitute for identifying and fixing that kind of inefficiency.
A minute spent waiting for a report is frustrating at any time of year. During extension season, when the same work is repeated across a firm and people have less flexibility in their schedules, removing that delay has an immediate practical value.
The Difference Between Being Online and Being Usable
Uptime is useful. It tells firms whether a system is available, and it gives vendors a common way to report service continuity. But it doesn’t fully describe what users experience inside an application.
Consider a practice management platform where employees can log in and view client records, but document uploads are failing. Or one where time entries don’t save reliably, leaving staff to reconstruct their hours later. The platform may still register as available even though important work has stopped.
This is why engineering teams need visibility into application response times, error rates, database behavior, service dependencies, and the health of important workflows. Those signals can reveal problems that infrastructure-level monitoring alone may miss. They also help distinguish an isolated slowdown from an issue that could affect other parts of the platform.
Software changes are another part of the equation. Even a thoroughly tested release can introduce unexpected issues. Close to a filing deadline, the impact of a disruption is greater, so the benefit of a change has to be weighed against its risk. That may call for adjustments to deployment schedules, additional testing, or limiting changes during particularly sensitive periods.
The goal is straightforward: enter peak season understanding where the platform might be under pressure, rather than discovering a weakness for the first time when firms are depending on it most.
Preparing for Problems That Can’t Always Be Prevented
Not every risk can be eliminated through testing or optimization. A cloud provider can experience an outage. A third-party integration can fail. An unexpected defect can affect a service, and a security incident may require access to be restricted while a threat is investigated.
For accounting firms, those dependencies are especially consequential. A single client workflow may involve tax preparation software, e-filing, e-signatures, email, and a practice management platform. When one connected service becomes unavailable, the effect can extend beyond that application. Documents may be delayed, returns may be held up, and staff can lose visibility into what is ready for review.
That makes it important to understand which components are critical, how they depend on one another, and how affected requests or workflows should be handled if a connected service is slow or unavailable. Redundancy can reduce the impact of certain failures. Backups and recovery procedures provide another layer of protection, but those procedures also need to be tested.
Recovery Time Objectives and Recovery Point Objectives help define expectations for restoring service and limiting potential data loss. They are useful only when supported by practical recovery plans. Similarly, incident response procedures need to establish who investigates, how severity is assessed, when additional people become involved, and how decisions are coordinated.
Security is part of this picture because protecting customer information can sometimes require temporarily restricting service. Qount has completed a SOC 2 Type II audit and holds ISO 27001 certification, which provide independent assurance within the scope of their assessments. Those credentials don’t replace the need for continuity and recovery planning.
The customer-facing response matters, too. If a disruption occurs near a deadline, firms need to know what is affected, what they can continue doing, and when they will receive another update. Engineering, support, and other customer-facing teams need to share information quickly, even when the cause or estimated recovery time isn’t yet clear. Once service is restored, reviewing the root cause and the response helps teams prepare for a similar event in the future.
What the October Deadline Showed Us
During the run-up to October 15, we reported no incidents on our public status page. Our most recent publicly reported incident was in December 2025.
That’s encouraging, but a status page is only one measure of reliability. Performance within the application and the experience of individual customers matter just as much.
One other encouraging signal came from support: requests during the first half of October were slightly lower than in early September, even as activity on the platform peaked. That doesn’t tell us everything about how every firm experienced the deadline, and it doesn’t by itself establish why support volume changed. It is one useful measure alongside performance and monitoring data.
Following a filing deadline, we can review where demand was highest, whether the infrastructure performed as expected, and where particular services showed signs of strain. We can also look at customer feedback for problems that might not stand out in overall system metrics.
A few additional seconds in a frequently used workflow may sound minor in a performance report. Repeated hundreds of times across a busy firm, that delay becomes operationally significant. Those are the kinds of details that should influence what gets improved before the next peak period.
The Work Continues After October 15
Our season-readiness work is continuing ahead of the next busy period in January. One area of focus is moving more of our infrastructure to automated, repeatable templates. Standardizing how infrastructure is configured can reduce manual steps and make changes more consistent as the platform evolves.
Each filing season gives us another opportunity to examine how Qount performs under demanding conditions and where our assumptions need to change. That work includes visible improvements, like the faster time reports, and less visible preparation around infrastructure, dependencies, and recovery.
For firms that depend on Qount to manage daily work, the outcome should be simple: critical workflows remain available and responsive when deadlines leave little room for disruption.
The work behind that outcome is ongoing. It means identifying weaknesses before they interrupt a firm’s day, preparing for the failures that can’t be predicted, and using what we learn from each deadline to make the platform stronger for the next one.
