Our YC application, published before we know the answer

We applied to Y Combinator for the Winter 2027 batch. Below is most of what we wrote.

Read it as an example, not as advice. We might not get in. If we don't, this post stays up unchanged. That is why I am posting it now instead of waiting. Almost every application you can read online was posted by someone who got in. By then the writer knows which answers worked, and rewrites the story around them. Nobody posts the one that was rejected. So you only get to learn from the winners. I don't know yet which one this is.

I've marked the answers I think are weak. Those marks are the useful part. If you are filling in the same form this month, skip the parts about our company and read the criticism.

Maintenance note, 17 September 2026: this remains a historical account of the submitted application. Equity, funding, revenue, customer-count, and traction figures are omitted under the company's current public-disclosure rule. An omission inside a quoted answer is marked rather than rewritten as a current claim.

The two videos

YC asks for a one-minute founder video and a demo. Both are below, as submitted.

The founder video is the three of us on a call, recorded in one take. Michele is in Piedmont, Teppo and I are in Helsinki, which is the company as it actually works rather than a set.

The demo is Teppo asking Skene a question a growth team would ask, "calculate the purchase_completed costs", and Skene answering that it cannot, because the event is not tracked. It then opens a pull request that adds the event. That is the product in twenty-six seconds, and it is the honest version: the interesting part is the answer we cannot give yet.

The address bar is blurred. The recording was made against a local build and the URL carried a session token.

What we told them we do

The fifty character version: turns GTM plans into event tracking and experiments. The long version is where the word count went.

Almost 1B commits were pushed to Github in 2025 and every commit can break the lines that record a signup, activation or campaign tracking. GTM teams work depend on that code and cannot run enough experiments, because they do not know if the data to prove the experiment exists. Skene closes the gap. GTM can turn the plans and campaigns into which event should be tracked to prove what works, and generate new experiments with our agents. The product checks that engineering has implemented the plans correctly (or we create a PR), reviews future PRs to make sure the tracking doesn't break with product updates, generates fixes if it does, and then runs experiments for GTM based on learnings.

The weak part is the first sentence. A billion commits is a big number about the world, not about us. Anyone who has been pitched before will skip past it. I wrote it because the answer felt like it needed a run-up. That instinct is what produces bad first sentences. The second sentence is the one that does the work, and it should have gone first.

So check your own first sentence. Does it say something, or is it just clearing your throat?

The company-number answers, omitted

The submitted application included revenue, pricing, team, and traction answers. Those figures are omitted under the company’s public-disclosure rule. This is a disclosure edit, not a correction to the historical application or evidence that its inputs were verified.

The pivot, which we could have hidden and did not

We launched an earlier product, then changed direction after its open-source adoption did not convert into Cloud usage. [Historical traction figures omitted.]

The open-source tool worked as software and failed as the route to a Cloud buyer. It remains published and maintained. What changed was who we sell to, not whether Skene OSS exists. This is the submitted application’s pivot account, not current conversion proof.

Techstars, 2017, and what an accelerator is actually for

I've been through one of these before. In 2017 GetJenny applied to Techstars, went to the finals in London, got cut, and was then offered a place in Tel Aviv. We took it.

It was a good experience and the value was almost entirely people. Greg Rogers and Chris Adelsbach, and alumni like Ben from Kard, are contacts I still have nine years later. The programme content mattered less than the room it put me in.

What I got wrong was expecting the programme to tell me what to build. It can't, and that isn't what it is for. It makes whatever you bring with you bigger. Bring nothing real and you waste three months. That is the honest reason we applied now and not a year ago. It is also why the application says we would move the company to New York afterwards. Our customers are there. We are in Helsinki. Being in the same city is the one thing money can't buy.

So if you are thinking about an accelerator, answer this first. What would you bring into the room? And does it get bigger by being there?

The bet we described under "other ideas you considered"

The application asks what else you thought about applying with. It notes that this is sometimes the answer they fund. Ours was self-maintaining APIs, which is close to what we already do. The observation under it is the one our distribution rests on. An API from a company like Supabase rarely breaks. That doesn't stop a developer, or a coding agent, from breaking the connection at their end.

The decision behind it is to support one database really well before supporting all of them. For us that database is Supabase. Supabase went through YC themselves, which I would rather say than pretend I hadn't noticed. That isn't the reason. The reason is that the data we need already sits in a Postgres database, and we can read its shape without asking anyone to move anything.

Write down what a bet like this costs you, before someone asks about it in an interview. Ours means we only reach companies on one database. Those companies may turn out to be smaller and younger than the ones that can pay us. If so, we will have spent a year reaching people who were never going to fund us. We would find out slowly, because small customers leave quietly.

The market answer, with figures omitted

The application estimated a market by multiplying an assumed company count by then-current pricing and compared that result with another vendor’s pricing. Those inputs and forecasts remain unverified, and the financial figures are omitted under the current public-disclosure rule.

The useful lesson survives: multiplying a total population by an entry price describes a ceiling, not likely market share. A market argument should state the population, attainable share, price basis, and evidence for each input.

Two questions, and then the outcome

We picked the wrong customer once already. The evidence took time to collect. So the first question is whether we've done it again. Is a GTM team the right buyer here? Or is the person who really feels the pain still an engineer who can't get anyone to prioritise fixing the tracking? If you have watched this go one way or the other inside a company, I want to hear it.

Second, for anyone who has written one of these that got in: what would you cut? Not what to add. The application is long and I suspect two of the answers above are doing no work at all.

Write to me at teemu@skene.ai or on LinkedIn. And if you are mid-application right now and want a second pair of eyes on yours, send it over. I'm not qualified to tell you it will work, but I'll tell you which sentence I'd delete.

I'll post the result here whichever way it goes.