CoreyPresso Network - the business Corey was built to run
One platform with three services for event organisers - ticketing, a progressive event app, and a white-label tier.
Presso Network is a UK events platform running ticketing, an event app and a white-label tier from one codebase. It is the company Corey was built inside - the operational load of running it solo is what produced the operating system, and Corey now runs Presso's recurring finance, content and reporting work.
What this is, on the record
- Started
- 04/02/2025
- Commits
- 697
- Status
- Running
- Who did what
- Built by Kristian Papadakis. Corey now runs the operational layer - it did not exist for most of the build.
- Built with
- Rails, Hotwire, Astro, Stripe Connect, Cloudflare, Neon Postgres
The project
Presso Network Ltd is a UK company selling to event organisers. It runs three services from one codebase: Presso Tickets for selling tickets, Presso Events for the progressive event app, and Presso Pro for organisers who want it on their own domain.
It has been built and run by one person since February 2025. Not one person plus a team, and not one person plus contractors. One.
That constraint is the whole story. A platform taking real money for real events has obligations that do not scale down: payments have to reconcile, VAT has to be right, customers need answering, and none of it pauses because you are shipping a feature that week.
What we did
The order was deliberate. Marketing site first, in February 2025, because you cannot sell what you cannot explain. The application followed in August 2025, once the offer had survived contact with actual organisers.
Payments came next and took the longest, because Stripe Connect on a platform that pays out to third parties is where the genuinely hard problems live - destination charges, onboarding, refunds, payouts, and the UK invoicing rules that sit underneath all of it.
Then the consoles: one for organisers, one for admin, each shipped in slices against a written spec rather than in one long branch. And underneath, a steady migration of the infrastructure onto Cloudflare and Neon.
The thing that was not planned was how much of the week the operational layer would eat. Not the building - the running. That is the gap Corey came out of.
What we decided
One platform, three services - not three products
Presso Tickets, Presso Events and Presso Pro share one codebase, one account and one dashboard. The alternative was three products with three funnels and three support surfaces, which one person cannot maintain. Naming discipline enforces it - they are always written as services of a platform, never as separate apps.
A flat 1% fee, with the per-attendee floor withdrawn
Pricing was originally a whichever-is-higher model - 1% of ticket sales, floored at £1 per active attendee per event day. It was retired on 09/07/2026 for a flat 1%, no minimum, the same whether or not the event app is enabled. The floor was defensible on a spreadsheet and impossible to explain on a sales call, and a price nobody can repeat back to you is a price that loses deals.
Presso Pro is an add-on, never a tier
Pro is Presso Events on your own domain, at £49 a month on top. Describing it as a premium tier implied the base service was the cut-down one. It cannot exist without Events enabled, and the positioning now says so.
Rails is the platform being migrated off
The app was built on Rails and is now legacy. New build defaults to a serverless stack on Cloudflare and Neon. Committing to that direction early meant the migration is a planned decline rather than a rewrite forced by a scaling wall.
What got built
- A Rails application covering ticketing, event pages and organiser tooling, at 242 commits.
- A marketing site rebuilt from Rails onto Astro and Cloudflare Pages, at 455 commits, with 301 redirects preserving every indexed URL.
- Stripe Connect payments with destination charges, hosted onboarding and UK invoicing.
- An organiser console and an admin console, each shipped in slices against a written spec.
- Infrastructure moved onto Cloudflare and Neon Postgres, with isolated staging.
What Corey runs now
The recurring finance work
Reconciliation, invoicing and chasing, the cash and runway figures, and the numbers an accountant will ask for at year end - prepared continuously rather than rebuilt each quarter.
The Command Center
One screen showing what needs a decision, ranked so compliance deadlines and approvals sit above build work, with each item linking to where it actually lives.
Content and reporting
Drafting in the company's voice, keeping to a calendar, and reporting what actually moved rather than what was published.
The approval boundary
Anything that reaches a customer, spends money or cannot be undone is prepared and then held. Corey proposes; a human decides.
Presso is where the operating system came from. Running a real UK company alone - the compliance, the payments, the recurring work that does not care how busy you are - is what forced the design decisions Corey now ships with: a memory of the business rather than a chat history, work that starts on a schedule rather than when you remember, and a hard line at anything that sends or spends. Corey was not designed and then tested on Presso. It was extracted from it.
Run yours the same way
Everything above is one operator across a portfolio. Corey is that operator, packaged. 28 days on us, no card.