What to answer before building fintech or event platform software

Most of the conversations that matter for a software project happen before a line of code gets written. Not the architecture discussions, not the sprint planning — the earlier ones, where you're working out what the system actually needs to do and what happens when it doesn't.

In fintech and event platforms, those conversations have a specific set of questions that are either worked through early or answered expensively later. Compliance requirements that surface after the architecture is set. Integrations that behave differently under real load than they did in testing. Traffic that arrives in spikes, with inventory errors or processing failures that have immediate, measurable consequences. Ownership that nobody defined at launch, creating quiet operational drift that takes months to notice and longer to fix.

The questions below are the ones worth sitting with in the briefing phase — before architectural decisions get made and before a development team is involved. Some will be easy to answer. Others will surface disagreements within your team, gaps in what's been defined, or assumptions that have been carrying more weight than they should. That's what they're for.

They apply whether you're building something new or evolving a system already running in production.

Understanding the problem space

What is this system actually being held accountable for?

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.

In fintech, that usually means something like: payment failure rate drops below a defined threshold within a set period after launch. Onboarding approval time reduced to a ceiling that keeps you competitive. Manual reconciliation time cut to a point where it stops consuming finance team capacity at the end of every settlement period. In event platforms, it's 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.

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.

Who is operating this under pressure, and what does pressure actually look like for them?

Roles shape logic and interface in obvious ways. The conditions those roles operate under get less attention, and they matter just as much.

A fraud analyst working through a queue of flagged transactions before a settlement window closes is operating under a very different set of constraints than a field agent completing KYC checks on a mobile device with an unreliable connection. Each has requirements that look reasonable in isolation and create real tension when they're sitting in the same system. 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 compliance tool and a field-facing mobile flow have almost nothing in common architecturally, even when they're drawing on the same underlying data.

Doing this early surfaces tensions between user groups that would otherwise stay invisible until the first build is in front of real people. Those tensions are exactly the kind of information that improves a design — and working through them before development starts is significantly cheaper than working through them after.

What are the non-negotiables that shape the architecture?

Scope and budget conversations happen early in most projects, and compliance conversations follow them. In fintech and event platforms, 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. A system designed without accounting for them has to be partially or substantially rebuilt to accommodate them, and that rebuild tends to happen when the product is already live and carrying real transactions or real ticket sales.

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 financial partner, or both. Are there existing infrastructure standards the new system has to operate within: specific hosting environments, databases, directory services, internal tooling that integration isn't optional for.

Some of these will have straightforward answers. Others will 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.

What has already been tried, and where did it break down?

Understanding what's been attempted before — internally and by competitors — compresses the time it takes to define what actually needs to be built.

An internal build that solved the immediate problem but couldn't scale identifies exactly where the architecture needs to be stronger this time. A third-party platform that created compliance gaps 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.

Competitor products are worth examining with the same specificity. In fintech, the question isn't just which payment or onboarding flows competitors have built, but where their users publicly report friction — verification delays, reconciliation errors, support failures during high transaction volume. In event platforms, it's where competing ticketing or entry systems visibly struggle: on-sale crashes, oversell incidents, integration failures with venue infrastructure. Those patterns reveal which problems are genuinely hard to solve at scale and which have been solved well enough that matching them is the starting point, not the goal.

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 prioritize, and they carry more information about actual requirements than any formal specification written from scratch.

Defining the scope, budget, and timeline

What is the smallest version that can go live safely?

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 fintech, it includes the core transaction or compliance flow, audit logging, and monitoring sufficient to catch failures before users encounter them. Dropping audit logging to move faster is a compliance problem that will need fixing under pressure later, not a scope trade-off. For event platforms, it's 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.

Being explicit about exclusions matters as much as defining what's in scope. Scope expands quietly — a decision here, an addition there — 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. Naming what moves to a subsequent phase, and why, is what keeps that from happening. A general prioritisation conversation rarely holds the line the way a documented exclusion 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? That's the line between a considered phasing decision and a problem deferred.

What are the real constraints on budget and timeline?

Budget and timeline conversations are often the most uncomfortable part of a briefing, and the discomfort usually produces vagueness at exactly the point where specificity matters most.

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. A payments infrastructure project and a consumer-facing event discovery product have very different cost profiles, and the right approach to each depends entirely on what resources are actually available. 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. Vagueness isn't.

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 banking partner 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 and becomes difficult to defend when the schedule tightens.

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. Projects that compress everything into a single go-live create the worst possible conditions for absorbing what goes wrong — and in fintech and event platforms, the first real test of a system under load tends to find things that testing didn't.

Preparing for production

Which integrations will behave differently in production than they do on paper?

External integrations are where project risk concentrates, and the reasons are usually subtler than a provider going down entirely. Payment providers that perform reliably in a sandbox behave differently under production load. Identity verification services have latency profiles that only become apparent when real volume arrives. 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 exactly 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 for testing before production. What the known failure modes are, and whether the provider has a status page or incident history worth reading.

That investigation doesn't need to be exhaustive — it needs to be honest. The goal is to surface the integrations that carry real risk early enough to design around them, rather than discovering their limits during a live event or a settlement cycle when there's the least capacity to deal with them.

How does the system behave when something partially fails?

Total outages are easier to plan for because they're visible. A provider is down, a service is unreachable, and the failure is obvious enough to respond to. 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. A verification service responding but returning inconsistent results for certain document types. 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? There's no single right answer — it depends on the flow, the dependency, and what the business can tolerate. But these are design decisions, and the time to make them is during the briefing, with the full picture visible, not during an incident when the options are narrower and the pressure is higher.

What is the failure scenario that would cause the most damage?

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 fintech products, that tends to be a payment processor outage during a peak settlement window, where transactions are queuing and finance teams are waiting on reconciliation that isn't coming. Or a verification provider going down and blocking new customer onboarding entirely, with no fallback and no clear timeline for recovery. Or a regulatory change arriving faster than the system can be adapted to accommodate it, with a compliance deadline that doesn't move.

For event platforms, it'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.

The value of working through these scenarios before launch isn't that it prevents them from happening. It's that a team with a pre-documented response — a fallback flow, a manual override process, a queue, a defined escalation path — can respond calmly and 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.

Who owns this the week after it goes live?

Launch is the point at which ownership questions that were left vague become immediately expensive. The system is live, real users are depending on it, and the development team's attention is already moving on to whatever comes next. If it isn't clear before that moment who is responsible for what, the gap becomes obvious quickly.

The accountabilities to define explicitly: who reviews monitoring alerts day-to-day, including at times when the business isn't otherwise operational. Who owns the decision to roll back during an active on-sale or a live settlement window, when the cost of being wrong in either direction is high. Who is tracking infrastructure costs as volume grows and the gap between projected and actual spend starts to open. Who is connecting product analytics back to the business metrics the project was built to move — and who acts on what they find.

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, each of these functions gets performed inconsistently or not at all — 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. Establishing that capacity under pressure after launch is significantly harder and more disruptive than it needs to be.

Starting well is most of the work

The problems that derail software projects — unclear scope, misaligned expectations, constraints that surface too late — are almost always visible before development starts. In fintech and event platforms specifically, the questions that are hardest to answer in a briefing room tend to be the most expensive to answer in production. 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 before development begins is the point.

For teams that want support working through them, we offer a structured discovery phase that covers the ground above in a focused engagement before build starts. It's designed to surface the requirements, constraints, and risks that are hardest to see from inside the project. If any of these are proving difficult to answer, get in touch. We can help you work through them and turn what you have into a brief that's actually ready to build from.

‍