.png)
Picture a ticket release for a sold-out tour. The countdown ends, several hundred people go for the last remaining tickets in the same second, and the payment provider starts answering slowly. The platform now has to keep two buyers from getting the same seat, hold every order in a consistent state, and recover cleanly from requests that time out, while more people keep arriving.
Event-tech products spend most of their lives quiet and earn a large share of their revenue in short, intense windows: a ticket release, a live auction, a fundraising deadline, an artist announcement. That shape of demand changes what a good development partner looks like. Delivering features on schedule matters, and so does the team's judgment about transactions, concentrated load, and how the system behaves in production when it counts.
Our view is that founders can choose a partner on three things: relevant engineering evidence, the quality of the discovery process, and a delivery plan that addresses the product's real risks. You bring a clear business direction. A complete technical specification can wait, because building one is what discovery is for, and it goes better as a joint effort between founders and engineers.
Founders come to agencies at every stage, from a pitch deck to a detailed requirements document. In our experience, the conversations that go best share a shape: the founder knows the business deeply, and the technical picture is still open.
The starting point is who the product serves, whether organizers, ticket buyers, bidders, donors, or attendees, and what it fixes for them that existing tools leave open. Next comes the revenue logic: who pays, for what, and what makes it commercially viable.
Most founders also carry a few assumptions that haven't met a paying customer yet. Organizers say they would switch platforms, or a fee model works on paper. Demand gets tested through customer conversations, pre-sales, or a manual pilot, and engineering feasibility gets tested through technical investigation and prototypes. An agency can help with the second kind. The first draws on the founder's market knowledge.
In a ticketing product, the main journey runs like this: a buyer joins a queue, picks seats, pays, and receives a confirmation. In an auction, a bidder watches a lot, places a bid, gets outbid, and bids again. These are the moments that carry the revenue, and they shape most of the engineering decisions that follow.
They also reveal the business rules the platform has to enforce. Can two buyers reserve the same seat? What happens when a payment is delayed? Which bid wins when two arrive almost together? What does a participant see when a transaction can't complete? The answers shape architecture, integrations, and testing.
Event traffic arrives in bursts. The useful details are what triggers a peak (a presale code, an announcement, a campaign deadline, the close of a bidding window), roughly how large it could be, and how long it lasts. Ranges are enough. "Between 2,000 and 10,000 people at release" is a perfectly good starting point.
The cost of failure belongs in the same picture: lost sales during a sellout, bids that never register, a donation page that freezes in the middle of a live appeal. That answer shows how much reliability engineering the product deserves.
The founder brings business context, goals, and known constraints such as the launch date, budget range, existing systems, and payment providers, along with whatever evidence exists: customer conversations, competitor research, early demand signals. The engineering team brings requirements, an architecture direction, a delivery plan, and early notice of technical risks. Priorities and commercial decisions stay with the founder. Technical recommendations come from the engineering team, with a clear statement of where it is still uncertain.
Open questions are welcome in the first conversation. A list of what's undecided makes honest scoping possible, since assumptions left unspoken tend to turn into scope and cost later.
Watch for: an agency that wants a complete technical specification before it will talk. A good partner expects to help write one.
Discovery is the work that sits between a business idea and a committed build. It connects what the founder wants to achieve with the technical decisions that shape cost, timeline, and reliability.
Discovery investigates the core workflows, the business rules behind them, and the requirements the product has to meet. Functional requirements describe what the product does. Non-functional requirements describe how well it has to do it: peak load, availability during an event, response times, recovery after a failure, data protection. The team maps dependencies such as payment providers, ticketing systems, and identity services, and writes down the constraints and assumptions the plan rests on.
From there the engineers propose an initial architecture direction and explain the trade-offs behind it in terms the business can weigh: cost, delivery time, reliability, flexibility, and maintenance. One design may keep implementation simple and limit later flexibility, while another takes more upfront work to support demanding peaks. The scope then separates what the first release needs from what can follow, so it reflects the product's real priorities.
Some questions can't be answered on paper. For those, the team and the founder decide together whether to investigate further, run a test, or accept a documented risk.
In event tech, a handful of scenarios decide whether the product works when it matters. Discovery walks through them, and section 3 returns to each one as a way to assess any agency.
Each scenario also raises business questions, such as how long a seat stays held while a payment is pending. The engineers can lay out the options and their consequences, and the founder makes the call. That exchange is a large part of what discovery is for.
Depending on the project, the outputs typically include:
The depth varies with the starting point. A product with existing requirements may need a focused review and validation. A greenfield product usually calls for broader work on workflows, architecture, and design. Either way, discovery ends with a decision both sides can see: proceed with the proposed scope, investigate a specific risk further, revise the plan, or revisit the product direction. Some uncertainty survives discovery, and it gets documented so it can be tracked.
Watch for: a confident fixed estimate offered before anyone has examined the assumptions that could change the work.
General software experience carries a lot of value, and a high-volume transactional platform draws on one specific part of it. These are the questions we would put to any team, ours included, because the answers show how an agency reasons when the stakes are concrete.
The most useful comparison is between technical challenges, since the event-tech label alone says little. An agency may have a dozen event sites in its portfolio and never have faced a traffic spike. Another may have built a flash-sale or booking system for a different industry and wrestled with the same problems of concurrent demand and transactional integrity. Good questions here: what load did the system face, what came close to breaking, and how did the team respond?
Role matters as much as portfolio: whether the agency built, maintained, or operated the system. A system inherited from a client or another vendor shows what the team observed, and the key design decisions may have been made elsewhere. Case studies and technical write-ups show it directly.
Performance numbers need context to mean anything. A peak of 5,000 requests per second tells you little until you know what those requests did, how the load was generated, and whether orders stayed correct and response times acceptable while it lasted.
RallyUp is a fundraising platform that supports nonprofits and other organizations running campaigns online, in person, and in hybrid formats. Most campaigns generate manageable traffic, but a high-profile fundraiser can bring a sudden surge of activity. During a campaign run by Tom Holland’s Brothers Trust, RallyUp handled approximately 250,000 requests per second.
The platform’s core is a modular .NET monolith, supported by specialized microservices. To handle demanding workloads, the team focuses on application performance, database efficiency, distributed caching, and infrastructure scaling. The platform uses Redis for distributed caching, and the team investigates slow queries and other performance bottlenecks as part of its ongoing work to keep fundraising campaigns responsive under load.
That work matters because fundraising campaigns often run around fixed events, when downtime can interrupt transactions and affect the participant experience. RallyUp’s engineering priorities reflect this: production bugs, stability improvements, and performance optimization come before planned feature development.
The five scenarios from section 2 give a practical structure for this conversation. For each one, the question is how the team tests it and what result counts as acceptable. Specific answers have a recognizable shape:
Beyond the scenarios, a credible plan includes measurable performance requirements: response time at peak, acceptable error rate, the conditions that must hold before launch. Architecture choices come with a rationale tied to the product's workflows and an honest account of their limits.
Watch for: broad scalability promises with no workload model or measurable targets behind them.
On security, the relevant areas are how the agency handles access control, secrets, dependencies, vulnerabilities, and sensitive data, and how the product's payment and privacy obligations get addressed. A vendor's certification, SOC 2 for example, covers that vendor's own environment. The product's compliance scope depends on how it handles payment and personal data, and gets its own plan.
Production readiness covers deployment, monitoring, alerting, logging, backups, and incident response. For a product tied to event windows, the sharpest question is who is watching the system during a release and what they do when response times start to climb.
Many engineering teams now use AI coding tools, and these can speed up implementation. The useful questions concern how generated changes are reviewed and tested, who stays accountable for the code, whether engineers can explain the system's behavior without the tool open, and how technical debt is tracked. Review and maintenance practices are where the evidence is. The number of tools in use says little.
The questions here are who leads architecture, implementation, testing, and production support, how available the key specialists are, and how the agency handles staffing changes mid-project. How the team communicates risk, escalates decisions, and responds when an important assumption turns out wrong matters as well. Former clients can speak to all of this, particularly to how the team behaved when something unexpected came up after launch.
Watch for: a gap between the people presented during sales and the team assigned to delivery.
By this point most founders have two or three candidates and a stack of proposals that look different from one another. The comparison works best on the same basis for every candidate, and the working terms get settled before the first sprint starts.
Laying every proposal against the same seven headings makes the differences visible:
Price only becomes comparable once scope and responsibilities line up. Two estimates for the same product can differ widely because one includes discovery, load testing, and production support and the other leaves them out. The reasoning behind a number tells you more than the number does, and a proposal that lists its assumptions gives you something to compare against reality later.
Some uncertainty is cheaper to resolve before the full build. A paid discovery phase fits when scope, feasibility, or architecture questions could materially change the project. A technical proof of concept fits when one specific engineering risk needs testing, such as a concurrency scenario at expected peak or a critical payment integration.
Either one works best with a defined purpose: the question it answers, the deliverables, the cost and timeline, and the decision that follows. A small feature built with no such question produces code and leaves the real uncertainty where it was. A proof of concept has limits too. A prototype that handles ten thousand simulated buyers has shown that one approach works under one test, and the complete production system still needs its own verification.
Before development starts, the parties agree on who owns product priorities, business rules, architecture decisions, and the acceptance of finished work, and which decisions the engineering team can make without a sign-off. Escalation paths for disagreements and slow answers belong in the same conversation, since delays on the client side affect the schedule as much as delays on the agency side.
The initial scope and acceptance criteria go in writing. Changes will come, so the process for assessing them matters: each one gets an estimate of its effect on cost, schedule, dependencies, and technical risk before anyone commits. The same process covers requirements discovered mid-build, which in our experience happens on nearly every project.
For event-tech products, acceptance criteria can carry the product's actual risks. Examples include behavior under an agreed load, correct handling of simultaneous purchases of the same inventory, and recovery from a specified payment-provider outage. Criteria like these are measurable, and they connect each milestone to the scenarios from section 2.
The founder's ownership of the product should be settled in writing: source code, repositories, cloud infrastructure, domains, deployment systems, and third-party accounts such as payment providers and email services. Access to all of it sits with the client from the start. Documentation and knowledge transfer get the same early attention, including where key technical and operational knowledge lives and how it stays current as the team changes.
The last item is the exit. If the engagement ends or the product moves to another team, the founder should be able to hand over a working system with its documentation and access intact. Agreeing on that process while the relationship is good makes it a routine piece of the contract.
After the conversations, references, and proposal reviews, a short list helps put the picture together. A "no" or "not yet" on any of these marks something to resolve before signing or to accept as a documented risk.
The questions carry different weights. For a high-volume event-tech product, gaps around transaction integrity, performance validation, and production readiness cost far more than differences in meeting cadence or reporting format. If the answers to 4 and 5 are weak, the other eight rarely make up for it.
A founder can start the search with a customer, a problem, a revenue model still to be tested, and a sense of when demand will surge. The specification comes later, out of discovery. What separates candidates is how they reason about the moments that decide the product’s fate: simultaneous purchases, a slow payment provider, a traffic spike that arrives within seconds.
Most of the signals described here can be observed in conversation. A team that has faced comparable load can say what nearly broke and what it changed. A proposal that lists its assumptions can be checked against reality later. Acceptance criteria written around peak behavior give each milestone a measurable meaning, and a named owner for production support means someone answers when the release window opens.
The ticket release from the opening will arrive on a particular day, with real buyers and a payment provider that may or may not behave. A partner’s value shows in how much of that day was worked out beforehand.
Think of us as your tech guide, providing support and solutions that evolve with your product.
.png)
