CoreyPresso Network - the business Corey was built to run
A UK events platform for organisers - one product, ticketing included, after two adjacent services were withdrawn.
Presso Network is a UK events platform running one product, Presso Events, with ticketing included. 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 its events product from one codebase. It once had three names - Presso Tickets for selling tickets, Presso Events for the progressive event app, and a planned Presso Pro for organisers who wanted it on their own domain. Tickets was folded into Events in August 2026 and Pro was withdrawn in September 2026, never having shipped or sold. What is left is one product, with ticketing included.
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
Three services collapsed into one product
The platform once carried three named services - Presso Tickets, Presso Events and Presso Pro - on one codebase, one account and one dashboard. Sharing the codebase was right; naming three of them was not. Tickets was folded into Events on 17/08/2026 and Pro was withdrawn on 10/09/2026, leaving one product with ticketing included. Three names meant three funnels, three support surfaces and three things to explain, which is three times the operational load for one person and no extra revenue.
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 was withdrawn rather than fixed
Pro was going to be Presso Events on the organiser's own domain, at £49 a month on top. Two problems killed it. Calling it a tier implied the base service was the cut-down one, and the add-on framing that fixed the positioning did not fix the economics - a custom-domain upgrade is real infrastructure to run for one organiser at a time. It was retired on 10/09/2026, unbuilt and unsold. Withdrawing a planned product before it ships costs a paragraph of copy; withdrawing one after it has customers costs a migration.
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.