.png)
In event tech, most failures are decided before a single line of code gets written—during the phase where teams define what the system needs to handle under real conditions: traffic spikes, concurrent transactions, and time-sensitive operations.
In platforms that process payments or sensitive data, those early conversations carry a specific set of risks. Compliance requirements that surface after architecture is set. Integrations that behave one way in testing and another under load. Traffic arriving in spikes, with inventory errors or processing failures that have immediate consequences. Ownership left undefined, creating operational drift that only becomes visible months later.
These systems are defined by two constraints: they operate in real time, and they handle high volumes of concurrent activity. That combination shapes every meaningful decision.
The questions below are the ones worth working through before architectural decisions are made and before a development team is involved. Some will be straightforward. Others will expose gaps, disagreements, or assumptions that haven’t been tested yet.
They apply whether you’re building from scratch or evolving a system already in production.
Before anything gets designed or scoped, it's worth being specific about what success looks like once the system is live — not in general terms, but the metrics that will tell you clearly whether the project delivered what it was supposed to.
For event platforms, that usually means: inventory accuracy maintained within a defined window during peak load. Entry throughput sufficient to clear a sold-out venue without queues forming before the event starts. On-sale uptime held through the first sixty minutes of a high-demand release. For products handling payments or data processing, it's payment failure rate below a defined threshold, manual reconciliation time cut to a point where it stops consuming team capacity, or onboarding time reduced to a ceiling that keeps you competitive.
Getting specific here shapes everything downstream. A team that knows it needs to hold inventory accuracy under concurrent load at ten thousand transactions per minute makes different technical decisions than one building toward a gentler traffic profile. The same applies to scope trade-offs, phasing choices, and where the architecture needs to carry the most resilience.
If the right metrics aren't obvious yet, starting with baselines is enough to move forward. Current processing volumes, drop-off rates, time currently spent on manual tasks. That creates a reference point and usually surfaces clarity about what the system is actually supposed to change.
Roles shape logic and interface in obvious ways. The conditions those roles operate under get less attention, and they matter just as much.
A back-office team processing transactions before a settlement window closes is operating under a very different set of constraints than a field agent completing checks on a mobile device with an unreliable connection. A promoter monitoring pre-sale volumes from a laptop the morning of a release has different needs from a venue operations team running handheld scanners during peak ingress for a sold-out show — where the queue is already forming and every second of validation delay is visible.
The details to map before anything gets designed: which roles interact with the system, what devices they're using, what the connectivity looks like in the environments they're actually working in, and what access constraints apply. A back-office tool and a field-facing mobile flow have almost nothing in common architecturally, even when they're drawing on the same underlying data.
Scope and budget conversations happen early in most projects, and compliance conversations follow them. That order creates problems. Regulatory requirements, data residency rules, and infrastructure constraints don't sit alongside architectural decisions — they determine what's possible in the first place.
The questions to settle first: which markets does the product operate in, and what data residency rules apply to each. Is payment card data in scope, and if so, what does PCI-DSS compliance require of the architecture. What audit trail obligations exist — mandated by a regulator, a contractual partner, or both. Are there existing infrastructure standards the new system has to operate within: specific hosting environments, databases, internal tooling that integration isn't optional for.
Some answers will be clear. Others require investigation — conversations with a compliance team, a legal adviser, or an existing infrastructure owner — before architectural decisions can responsibly be made. Finding a compliance requirement early costs an afternoon. Finding the same requirement after the architecture is set is measured in months.
Previous attempts—internal builds or third-party platforms—usually show where the system needs to be stronger.
An internal build that solved the immediate problem failed under load points to concurrency and scaling issues. A third-party platform that created compliance gaps or proved impossible to customise points to requirements that off-the-shelf solutions in this space consistently underserve. Either way, the history is useful — not as a post-mortem, but as a map of the constraints the new system has to be designed around from the start.
For teams starting from scratch, the equivalent is mapping the workarounds currently standing in for real functionality. The spreadsheets, the manual processes, the makeshift flows the business has been running on. Those workarounds point directly at what the first release needs to prioritise, and they carry more information about actual requirements than any formal specification written from scratch.
The first release should be the smallest version that can operate safely in production and deliver the outcome the project was built to achieve. In regulated or high-traffic products, that floor is higher than it might first appear.
For event platforms, the minimum includes the ticketing or registration flow, real-time inventory management with concurrency handled correctly, and a reliable entry validation path. A platform that goes live without inventory locking under concurrent writes has a liability waiting for a high-demand on-sale to expose it. For products handling payments or sensitive data, audit logging and monitoring sufficient to catch failures before users encounter them are part of the floor — not scope that can move to a later phase.
Being explicit about exclusions matters as much as defining what's in scope. Scope expands quietly, and the cumulative effect tends to be a release that arrives late, costs more than planned, and still doesn't quite reflect what the project originally set out to do. A documented exclusion holds the line in a way that a general prioritisation conversation rarely does.
The question to ask for every item under consideration: does the first release work safely and meaningfully without this, or does leaving it out create a risk that's worse than the cost of including it?
Budget shapes everything downstream: which architecture decisions are realistic, what team composition makes sense, how deeply any given part of the system can be properly built. Sharing a specific number — along with an honest range for how much variation the business can absorb — makes it possible to propose something calibrated to the actual situation. A ceiling, even an uncertain one, is enough to make planning meaningful.
On timeline, the distinction to make early is between dates that exist because something external requires them and dates that were chosen because they seemed achievable. A regulatory filing window, a contractual go-live clause, a flagship event the platform needs to be operational before — these are constraints to build a plan around. A target quarter selected in a planning meeting tends to compress everything quietly.
Staged delivery is worth building into the plan from the start. An internal pilot, a controlled rollout with a limited user group, and a validation period before full-scale operation give each phase room to surface problems before they compound. In event platforms especially, the first real test of a system under load tends to find things that testing didn't.
External integrations are where project risk concentrates. Payment providers that perform reliably in a sandbox behave differently under production load. Ticketing and inventory systems have data contracts that look clean in documentation and turn out to have edge cases once real transactions flow through them. Background syncs appear healthy and fail silently for hours before anyone notices.
The failure modes that integrations introduce tend to surface at the worst possible moment — during an on-sale event, at end-of-day settlement, during peak ingress. Not because the timing is unlucky, but because those are the conditions that expose the gap between how an integration behaves in testing and how it behaves under load.
Every integration the product depends on is worth investigating before build begins: what documentation actually exists and how current it is, what rate and throughput limits apply and what happens when they're hit, whether a functional sandbox is available, and what the known failure modes are.
Total outages are easier to plan for because they're visible. Partial failures are more common and often more damaging precisely because they're harder to detect.
A payment processor accepting requests but timing out on a subset of them. An inventory system updating correctly for most transactions but silently dropping a small percentage under peak load. In each case, the system appears to be working. Monitoring may not flag anything. The problem accumulates quietly until the volume of affected transactions makes it impossible to ignore — at which point untangling what happened is significantly harder than it would have been if the failure mode had been anticipated.
For each critical flow, the question to answer in advance is how the system should behave when a dependency is degraded. Does it queue transactions and process them on recovery? Surface a clean error and allow a retry? Fail gracefully without exposing the underlying problem to the user? These are design decisions, and the time to make them is during the discovery phase — with the full picture visible, not during an incident when the options are narrower.
Working through a general risk register has limited value. The more useful exercise is identifying the specific scenario that would cause the most harm to the business — and deciding in advance what the response would be.
For event platforms, that's typically inventory desyncing during a high-demand on-sale, when the window to correct the problem is measured in minutes. Entry validation failing at scale during venue ingress, where a physical queue gets longer with every minute the system is degraded. Refund processing failing after an event cancellation, when the volume of affected customers and the pressure to resolve it arrive simultaneously. For products handling payments, it's a processor outage during a peak settlement window, or a third-party service going down and blocking a critical user flow with no fallback and no clear recovery timeline.
The value of working through these scenarios before launch is that a team with a pre-documented response — a fallback flow, a manual override process, a queue, a defined escalation path — can respond systematically rather than improvising under pressure. The scenario that causes the most damage is rarely the one nobody saw coming. It's usually the one everyone knew was possible and assumed someone else had a plan for.
Launch is the point at which ownership questions that were left vague become immediately expensive.
The accountabilities to define explicitly: who reviews monitoring alerts day-to-day, including outside normal business hours. Who owns the decision to roll back during an active on-sale or a live settlement window. Who is tracking infrastructure costs as volume grows. Who is connecting product analytics back to the business metrics the project was built to move.
These don't all need to be different people. In a small team they probably won't be. But they do need to be named. Without that, monitoring alerts go unreviewed, costs accumulate without scrutiny, and small failures that would have been cheap to fix compound into expensive ones over months.
If internal capacity to own these functions doesn't exist yet, building handover and documentation time into the project plan before launch is the right moment to address it.
The problems that derail software projects — unclear scope, misaligned expectations, constraints that surface too late — are almost always visible before development starts. A compliance requirement that takes an afternoon to surface and three months to retrofit. An integration limit that takes an hour to investigate and a week to work around once it's hit during a live on-sale. An ownership gap that takes ten minutes to define and creates months of operational drift when it isn't.
Some of the questions above will be straightforward. Others will surface disagreements within your team, gaps in what's been defined, or assumptions that have been carrying more weight than anyone realised. Finding those things in the discovery phase is the point. It’s worth resolving them before moving into implementation.
Think of us as your tech guide, providing support and solutions that evolve with your product.
.png)
