Building DailyHair — From Zero to 200 Events Handled in 12 Months

In Q2 2025, at the Cupra conference in Warsaw with 47 media partners, an email from the coordinator landed at 22:47: “For the fourth time this week Forbes is moving the deadline. Wyborcza wants a different brief than TVN24. I have all of this in Excel across three tabs, but by 6:00 tomorrow I have to send 47 separate summaries and I no longer know who stands where.” Attached was a screenshot of the spreadsheet, with tally marks for deadlines she had verbally agreed to by phone. Two hours later came the industry conference we co-organized — the first one where we watched the same pattern unfold for three communications managers in a row. That same week we started building DailyHair.

The number “47 media patrons” wasn’t impressive on its own. It was a symptom of an operational architecture that no generic event tool addresses. The communications manager wasn’t running an event; she was firefighting between two worlds, an organizer who wants maximum visibility, and media houses that want maximum value for their patronage.

DailyHair brought together the three conditions we look for in every venture-building partnership. First: an expert with 12 years in PR and event communications and a list of 30 friendly organizers ready to test the product — that wasn’t a hypothesis, it was distribution on day one. Second: a market of 1,500 Polish conferences a year running media patronage, where serving 15% already means 200+ SaaS customers. Third, and the hardest: zero tolerance from our partner for software requiring two-hour onboarding mid-event-sprint — which operationally meant every feature had to work in 5 minutes or not exist. Operationally, those three conditions looked like the rare moment when idea, distribution, and scope discipline sit in the same pair of hands.

Why we didn’t build another Eventbrite

Eventbrite, Evenea, and Konfeo are good for the masses. They are pragmatic tools for the organizer who wants to “have online ticketing” and not differentiate beyond that. But the market we cared about — industry events and conferences with budgets above 200K PLN, where media patronage and sponsorship form a meaningful part of financing — has specific needs that generic ticketing doesn’t address.

First: media patronage as a first-class object. A patronage isn’t a “FREE category ticket.” It’s an agreement with a media house where both sides have obligations (publishing a preview, social posts, a banner at the conference in exchange for logo placement, a mention, and a ticket allocation). Each patronage has its own brief, its own asset package, its own deadlines, its own post-event report. There was no tool that natively understood this two-way contract.

Second: patronage tiers. A main patron plus press patron plus radio patron plus online patron is not four separate contracts — it’s one event with a tier-variant package for each level. Eventbrite handles this poorly; the platform forces a rigid role catalog that doesn’t match real-world media-partnership hierarchies.

Third: media-specific rules. “Wyborcza” only publishes previews 21 days before the event, “Forbes” requires an exclusive interview with a speaker, a regional radio station needs a ready-made MP3 spot. In a generic tool every medium gets the same brief. In real patronage management every partner has its own rhythm, format, and deliverables checklist. We needed a system that understood these rules natively, not one that worked around them through spreadsheet comments.

Fourth: settlement of patronage value in EAV (Equivalent Advertising Value), not in tickets. A media patron returns to the organizer who delivered 4-6× value back in publications, on-site exposure, and post-event data. Not to the one who handed over a stack of tickets. Value settlement is the foundation of patronage renewal. In practice that meant a different data model from typical event SaaS: medium as a first-class object with ROI history, event as a container.

Venture Builder vs. Software House — what do scale-ups pick?

Dimension	Software House	Venture Builder
Billing model	Invoice for hours / scope	Reduced flat fee + equity stake
Decision horizon	Until project handover	5+ years, shared P&L
Optimizes for	Scope and budget	Retention, MRR, ARR
Who carries product risk	Client	Both sides — shareholders
Feature decision	”Client asks, we build"	"Will this move retention?”
What happens after deploy	Invoice, hourly support	Team stays — it’s their company
Partner profile	Anyone with a budget	Industry expert + distribution + scale

Scale-ups with distribution on day one (a list of 30+ friendly users, pilot contracts at conferences, niche validation) pick venture builder, because scope discipline and shared upside compress 24 months into 12. The rest — software house, invoice, clean boundary. The full framework is laid out in our venture builder services.

The model: venture building, not project work

Our partner came with the idea, twelve years of experience in PR and event communications, and a list of 30 friendly industry organizers who promised to test the product. We came with technology, experience building and scaling SaaS, and the business architecture we’d learned across 11 other products in the Do More Soft Venture Builder ecosystem.

We could have priced the project as bespoke software — about 380-420K PLN for the MVP plus maintenance. We could have run it T&M with a two-month buffer and a regular invoice. We could have proposed classic fixed-price with penalty clauses for delays. We could even have declined, because the scale of the PL event market is smaller than most pitches that land on our desk.

Instead we proposed a company structure where we became co-shareholders, and our compensation for the first 12 months was reduced to covering core team costs. The gap between market valuation and the amount actually paid out became our investment in equity.

That decision changes everything. A software house optimizes for project scope and budget. A venture builder optimizes for retention metrics, MRR, and ARR. You don’t build features on speculation, because every unnecessary hour reduces the value of your investment. You don’t ignore user feedback, because they’re your customers. You don’t walk away after the invoice clears, because there is no invoice — there’s a shared P&L. Skin in the game isn’t a slogan; it’s a tool of scope discipline.

Build phases — from concept to 200 events

The full cycle — from the first conversation with our partner to 200 events handled — took 12 months. We split it into four discrete phases with clear transition criteria between them.

Phase 1: Discovery (4 weeks)

Four weeks with organizers and media before a single line of code was written. 22 interviews — with conference communications managers, with section editors at portals, with marketing directors at regional media. Each interview was two hours of workflow observation plus an hour of structured questions.

What came out of those 22 interviews was something we wouldn’t have assumed in any pre-discovery brainstorm: communications managers don’t need “a better event platform.” They need a system that takes them out of the role of human API between 47 newsrooms. That single observation defined the architecture — and cut three modules off the roadmap that had previously looked obvious.

The result was surprising on another front. The three biggest pain points weren’t about ticketing or the event website. The first was channel fragmentation with patrons (email + Messenger + external Slack + WeTransfer + phone). The second — no real-time visibility on the status of patron deliverables (the organizer doesn’t know whether “Wyborcza” has already shipped the preview, whether it’s stuck in editorial review, or whether the editor is waiting on a corrected photo). The third — no hard data to settle patronage value post-event (how many people from which medium showed up, how many publications ran, what the total reach was vs. the market value of the package).

That insight defined the product architecture. DailyHair was not going to be a “ticketing platform” — it was going to be an operational system for managing patronage and communications around an event. That reframe saved us three months of work on scope that wouldn’t have mattered to users. Our discovery process is a filter — and this time it worked exactly as designed.

Phase 2: MVP (8 weeks)

Eight weeks for three things: media patronage management (CRUD for partners, packages, deliverable deadlines), an asset center (briefs, files, drafts, approvals), and a status dashboard (who, what, by when, in what state). No ticketing. No mobile app. No analytics beyond basic product metrics. No integrations with external comms tools.

Eight weeks isn’t pace — it’s a filter. If you can’t deliver something users can evaluate in that window, the project has a structural problem — either in scope, or in architecture, or in the team. At DailyHair, the scope fit into eight weeks because we cut everything that wasn’t essential to the first real test with a conference.

We picked the stack pragmatically: React on the frontend, Node.js with Express on the backend, PostgreSQL as the database, deployed on AWS ECS with S3 for storing patronage assets (logos, photos, banners, audio files for radio spots). No technology experiments, no overengineering. The goal was reaching the first user, not building a platform for ten years.

Phase 3: Pilot (3 months)

Eight industry conferences in Q1 2025 — from boutique tech meetups in Kraków (200-400 attendees) to two large marketing conferences in Warsaw (1500-2000 attendees), among them the Cupra conference mentioned earlier with its 47 media patrons. Each event with hands-on onboarding led personally by the product co-founder. A 48-hour feedback loop — every reported request received a response (even if it was “we’re not doing that”) within two business days, and one in five made it into the backlog with a one-week implementation priority.

The pilot revealed three things no amount of discovery would have predicted. First: communications managers don’t want to log into the platform to approve materials — they want to approve through a link in an email, no account required. That overturned our UX assumptions and forced us to design a “magic-link approval flow” for patrons. Second: organizers want to see total EAV (Equivalent Advertising Value) of all patronages live, not only in a post-event report — because it’s an argument for commercial sponsors to expand their contract. Third: editors at media houses require ready-made “press kits” within 24 hours of patronage confirmation — the earlier MVP didn’t have this flow, we shipped it in the third pilot sprint.

Three months of pilot was the most valuable investment of the entire project. Without it we would have scaled a product that doesn’t address real user needs.

Phase 4: Scaling (6 months)

From eight pilot events to two hundred handled. In this phase we shipped a Flutter mobile app (one codebase for iOS and Android) for on-site event managers, integrated Google Calendar and Outlook to sync patronage deadlines, automated post-event PDF reports for every patron, and integrated with media monitoring platforms (Press-Service, Newspoint) for automatic publication tallying. Growth happened in two channels: word-of-mouth between organizers (on average each handled event referred 1.7 more organizers in the first quarter after the event) and a referral program among communications managers (a manager moving employers carried their DailyHair experience with them and naturally promoted the platform at the new organizer).

Across six months of scaling we didn’t spend a złoty on paid advertising. Word-of-mouth ROI was high enough that any spend on paid marketing would have been suboptimal versus investing in onboarding quality and support response time. That decision required discipline — the “let’s run LinkedIn ads” pressure came back monthly — but the math didn’t justify it.

Technology as leverage, not a goal

DailyHair’s tech stack is a deliberate choice for conservative options. React, Node.js, and PostgreSQL is the combination where the team has the deepest expertise and where the library and tooling ecosystem is richest. We weren’t looking for an edge in the technology layer — we were looking for an edge in delivery pace and UX quality. The same decision framework drove Cupra mycarapp, where the technology layer was meant to be invisible and the product was measured by retention.

Magic-link approval (instead of full login for patrons) is the decision that removed the biggest friction in adoption among media. The editor receives a link in an email, clicks, approves the material or rejects it with a comment, done. We saved at least three months of work on a roles-and-permissions system, while raising patron response from ~40 percent to over 80 percent in the first quarter.

Flutter instead of native iOS and Android apps is a math-driven decision: one codebase, one mobile team, one iteration cadence. We lose about 15 percent of native UI perfection, we gain twice the development speed and twice the lower maintenance cost. In a 40-percent-monthly-growth phase, pace matters more than native perfection.

AWS S3 for patronage assets is obvious — storage with no infra ownership, built-in CDN (CloudFront), marginal cost per event. Same argument: don’t build infrastructure you don’t have to. We laid out the detailed stack-selection logic in the context of bespoke software — the same decision framework we apply to every venture-building project.

First year — what worked, what didn’t

A brutally honest accounting for 12 months.

What worked. Word-of-mouth between organizers turned out to be a far stronger channel than we expected — the events industry is densely networked, communications managers know each other personally, and a recommendation from a friendly organizer carries more weight than a case study and demo combined. The asset center with magic-link approval — a feature competitors didn’t have at all — became the main sales argument; over 70 percent of organizers said in a post-event survey that this functionality alone tipped them toward DailyHair. EAV post-event reports were embraced by marketing directors — they satisfied a need for hard proof of patronage value that no other tool delivers (an Excel sheet tallied manually after the event convinces no one).

What didn’t work. The first version of patron email notifications had a 24 percent open rate — well below the B2B benchmark. After analysis it turned out the template looked like a transactional notification from a SaaS system, not a personal message from a communications manager. We redesigned the templates to a “personal email with a link” format; open rate jumped to 62 percent. The first try-and-buy for small events (up to 300 attendees) with the first event free didn’t generate conversions — it turned out that segment has too few media patrons (1-2 per event) for the tool to make sense. We retired that plan and focused on events with 8+ patrons. The most expensive failure was the cross-sell attempt to full-service event agencies — different user persona (account managers running 5 events at once), different pricing model, per-seat pricing breaking the math. After two months we backed out and parked that segment as a separate product line. Cost of that lesson: about six weeks of team time plus opportunity cost.

Metrics after 12 months

Three of those numbers are scope discipline, one is network distribution. Scale with no rescue-mode mid-year — because there was nothing to rescue, decisions landed weekly, not quarterly.

40 percent month-over-month is realistic in the first six months while the starting base is small — afterwards it stabilizes at 10-15 percent monthly, which at a base of 200 events means 20-30 new events per month. NPS 64 among event managers is exceptionally high for B2B SaaS (industry benchmark is 30-40) and we read it as a signal that the platform genuinely solves the problem, not just that people are using it. ARR in the “low 7-figures” range means a level that, given the current cost structure, gives unit profitability — every new event has positive margin from first use thanks to self-service onboarding (initially assisted, today 75 percent of organizers spin up without a support contact).

Lessons for other venture builders

Three observations we took from DailyHair into subsequent ecosystem projects.

First: skin in the game changes decisions at a level that’s hard to predict before entering the model. When you’re a shareholder, you don’t build features on speculation, you don’t take side projects that distract the team, you don’t promise deadlines you can’t keep. Scope discipline emerges from the structure of the agreement, not from good intentions.

Second: industry-specific wins over generic always, provided the industry is large enough. The Polish industry-event and conference market has over 8,000 active events per year, of which roughly 1,500 manage media patronage at a scale that justifies a platform. If you serve 15 percent, you have 200+ SaaS customers — a size at which the industry-specific product has better unit economics than a generic tool with a large base but low ARPU. The same equation holds in every large vertical: legaltech, automotive, medtech, real estate.

Third, and the hardest: an MVP in 8 weeks isn’t a starting line, it’s a filter. If a team can’t deliver a test version to users within eight weeks, the problem isn’t time — it’s scope, architecture, or the team. The MVP in 8 Weeks framework isn’t a promise of pace; it’s a tool for verifying whether a project has any chance of scaling at all.

What’s next for DailyHair

The next 18 months has logic, not a checklist. The Polish industry-event market is approaching the addressable ceiling at the current value proposition — 200+ customers already represents 13% of the niche, and the marginal cost-of-acquisition curve will climb unless we change one of three vectors. Hence the order.

Geographic expansion goes first, because DailyHair’s unit economics are strong (positive unit margin from the first event) and the DACH market has 2.3× higher ARPU than Poland at the same media-patronage structure. Q3 2026 — Germany and Austria. Q4 2026 — Czechia, Hungary, Romania. In-field discovery precedes every entry, because the Polish playbook doesn’t transfer 1:1 in scale: the German conference market has a stronger presence of vertical media (Heise, c’t, Computerwoche) and a different publication rhythm than Poland.

New segments — cultural festivals and B2B trade shows — are an extension of the existing platform without changing core architecture. Festivals because of the longer media-patronage cycle (3-6 months instead of 4-8 weeks) and the higher weight of regional media. Trade shows because of the sponsor-booth management module, which shares 70% of its logic with the media-patronage module. Both paths cost less than entering a new geographic market, but yield smaller marginal ARR.

The data layer as a product — that’s the lever. At 200+ events we hold anonymized data on media-patronage market trends (average package values per industry, publication deadlines by media type, partner retention rates between event editions). It’s an asset that, properly productized, becomes a second revenue stream: an industry report for event agencies, benchmarks for new organizers, reference data for media houses pricing their own patronage packages. The margin on that product would be respectable, because the data already exists — the cost is distribution and maintaining the reporting layer.

We launch those three vectors in parallel, not sequentially. Sequence is the privilege of startups with a 36-month runway. We have a P&L and competitors who haven’t responded to our lead yet but will within 12-18 months.

Have a product and looking for a partner, not a vendor?

If you have industry experience, a problem worth solving, and you’re ready to share risk with a competent technology partner instead of issuing an invoice for hours — let’s talk venture building. Describe the project in the configurator or write directly to office@domoresoft.com with the subject “Venture building partnership.” Scoping takes 2-4 weeks; the first conversation is free of charge but not free of specifics. If you’d rather understand the model before reaching out, read how Do More Soft became a venture builder and look at the about page.

FAQ

What is venture building in software? A partnership model in which the technology team takes equity in the product company in exchange for a reduced rate covering core costs. Skin in the game reshapes every scope decision — every unnecessary hour reduces the value of your own investment.

How long does it take to build a SaaS MVP? 8 weeks for the scope of a single problem with a clear validation filter. That isn’t pace, it’s a filter — if a team can’t deliver in 8 weeks, the problem sits in scope, architecture, or the team.

How does a software house differ from a venture builder? A software house optimizes for scope and budget, invoices, and walks away. A venture builder optimizes for retention, MRR, and ARR, holds equity, stays for 5+ years. That distinction filters out 90% of the pitches that land on our desk.

How much equity do you keep in a venture-building partnership? The majority — typically 60-75% for the industry partner, the remainder for the technology team. Proportions hinge on product stage, technology risk, and operational contribution. At DailyHair we reduced our rate by ~40% of the market valuation in exchange for equity.