Finding First Customer

The first customer is not just a sales milestone. In Pylon's early story, a real customer helped turn an uncertain idea into evidence about what to build.

Marty Kausas and his co-founders, Advith Chelikani and Robert Eng, eventually built Pylon, a B2B customer-support platform. Y Combinator lists Pylon as a Winter 2023 company and identifies the three founders. Kausas has publicly described the company getting its first customer within 14 days.

Kausas did not begin Pylon with a neat product brief. In public interviews, he describes spending months exploring startup ideas and speaking with potential customers rather than assuming that a problem he personally experienced would automatically make a good company.

The eventual insight came from a change in how B2B companies communicated with customers. More customer conversations were happening in shared Slack and Microsoft Teams channels, while traditional support systems had been designed around email and other conventional support channels.

A support team could therefore have important customer conversations happening in chat while the formal support workflow remained somewhere else. The problem was not simply that Slack existed. It was that an important customer workflow was happening outside the system responsible for organizing it.

Pylon's first product direction came from that gap.

According to Kausas's later account of Pylon's early days, the founders took the idea to a Y Combinator office-hours conversation almost immediately. The reaction was not a guarantee that the idea would work. They were told similar ideas had been tried before.

Instead of treating that reaction as the end of the idea, the founders used the next window to get closer to evidence.

Later accounts describe a two-week window in which the founders built an initial product and got it into the hands of their first customer. Kausas has also described Pylon reaching its first customer in 14 days. A later reconstruction of the founder story identifies Hightouch as the early first-customer relationship around the initial product.

The important part is not the number 14.

It is that an argument about whether the idea was good was replaced by a real customer using something the founders had built.

The early product was much narrower than Pylon's current platform.

The founders did not need to prove that they could build an entire customer-support company. They needed to prove one useful workflow.

The initial wedge focused on customer conversations happening in shared Slack channels. The product gave a team a way to turn a customer message into a support workflow rather than leaving the conversation isolated inside chat.

That is a different definition of an MVP from "the smallest version of the final product."

The useful MVP was the smallest product that could test the critical assumption:

Will a real B2B company use this workflow to solve a real customer-support problem?

Once that question had a live answer, the product could become more ambitious.

A founder can get feedback from almost anyone.

A customer who has agreed to use the product creates a different kind of feedback loop.

They can show you:

• where the workflow breaks;
• which part of the problem is urgent;
• what they are willing to change;
• which missing capability prevents adoption;
• what they already built themselves;
• what they consider valuable enough to keep using.

The first customer is therefore not merely proof that the founder can sell. The relationship can become an instrument for discovering the product boundary.

Later accounts describe Hightouch as having an internal solution for the same general problem. That is useful context, but it does not make Hightouch representative of every B2B buyer. It was one company, at one stage, with its own workflow and constraints.

Fourteen days sounds like the lesson.

It is not.

The more transferable pattern is:

Find a painful problem → get close to a real buyer → reduce the product to one testable workflow → put it in use → learn from the usage.

A founder who copies the deadline without the customer relationship may simply produce a rushed product.

A founder who copies the learning loop can adapt the timing to the problem.

Some products can be tested in days. Others require security review, integrations, physical production, regulatory work or operational setup before a meaningful customer test is possible.

Speed is useful when it shortens the distance between an assumption and evidence.

Pylon's early customer story is evidence about one company's learning process. It is not proof that:

• every startup should sell before building;
• every first customer should receive a customized product;
• a two-week MVP is enough for every market;
• customer feedback automatically produces product-market fit;
• a first customer guarantees future growth.

Pylon later became a venture-backed company with substantial funding and a much larger product. That later outcome should not be used to pretend the early decisions were obviously correct at the time.

That is survivorship bias.

The useful part is the sequence of decisions and evidence, not the mythology of eventual success.

Before approaching the first customer, write down the assumption you are testing.

For example:

"We believe operations leaders at B2B software companies need a better way to manage customer conversations that happen in shared Slack channels."

Then define what would count as evidence.

A useful first-customer test might require the buyer to:

1. agree that the problem exists;
2. explain how they handle it today;
3. try the proposed workflow;
4. use it with real work;
5. identify what prevents continued use;
6. explain what value would make continued payment sensible.

This is stronger than asking, "Do you like the idea?"

People can like an idea and never use it.

Usage creates friction.

Payment creates another layer of evidence.

Continued usage creates another.

Once a founder finally gets a customer, that customer can become the entire roadmap.

That is not validation. It can become dependency.

A first customer may expose a problem that is specific to their internal process, valuable only at their scale, expensive to support, difficult to generalize, or unrelated to the core problem other target customers have.

So after every customer request, ask:

Is this evidence about the market, or merely a requirement of this account?

If several target customers independently show the same problem, the signal becomes stronger.

If only one customer needs it, the right response may be a paid customization, a scoped experiment, or a decision not to build it.

A founder can explain a problem perfectly and still be wrong about its urgency.

A real customer interaction tests the assumption.

The first customer does not need the whole company.

They need one meaningful outcome.

The product should be large enough to create real value and small enough that the team can learn quickly.

Listen carefully.

Do not automatically build every request.

Look for repeated problems across the customers you actually want.

The fastest team is not necessarily the team that writes the most code.

It is the team that learns which assumption is wrong before spending another month building around it.

If you are still searching for your first customer, do not begin with a hundred-person sales plan.

Begin with one sentence:

Who has the problem, what are they doing today, and what evidence would convince you that they would pay for a better solution?

Then find a small number of people who actually fit that description.

The goal of the first conversation is not to make them excited.

The goal is to understand whether the problem is real.

The goal of the first product test is not to prove that your vision is correct.

The goal is to learn whether one useful piece of that vision survives contact with reality.

That is what makes a first customer valuable.

Not the logo.

Not the announcement.

The evidence.

The next questions matter more than the first sale:

• Did the customer actually use the product?
• Did they return without being chased?
• Did the product become part of a real workflow?
• What problem made them continue?
• What almost made them stop?
• Which requests are repeated by other target customers?
• Would another customer pay for the same outcome?
• Can the delivery process become repeatable?

A first customer answers very little by themselves.

A first customer plus repeated evidence can begin to change what you know.

This story uses public company information and founder interviews. SOE separates documented facts from editorial interpretation.

The documented facts used here are that Pylon was founded by Marty Kausas, Advith Chelikani and Robert Eng; that Y Combinator lists Pylon in its Winter 2023 batch; that Kausas has publicly described the company reaching its first customer within 14 days; and that later reporting identifies Hightouch in the early first-customer story.

SOE does not claim that Pylon's experience is representative of all startups. The transferable lessons are editorial synthesis from the documented sequence, not statements made by Pylon.

Sources checked

• Y Combinator, Pylon company profile.
• EO interview with Marty Kausas, including his account of Pylon's first-customer timeline.
• Get the Check interview with Marty Kausas, covering Pylon's founding, early product and customer-development approach.
• Product Market Fit Show's reconstruction of Kausas's early Pylon story, including the two-week YC interview window and Hightouch context.

Editorial note: No invented interview, first-person experience, customer quote, credential, metric or outcome has been added. Where a source describes a founder's recollection, SOE attributes it as a reported account rather than presenting it as independently witnessed fact.

This article should be read alongside the nearest SOE Knowledge Objects covering the same problem, stage, and next decision. Use those related pages to compare evidence, context, and implementation choices rather than treating this page as a standalone rule.

Related reading: \2 · \2

This page is presented as an illustrative founder story rather than a documented biography or verified case study. The narrative is useful for the decision pattern it exposes; readers should not treat unnamed events, outcomes or dialogue as independently verified facts.

Identify the specific decision, the evidence available at the time, the trade-off the founder accepted, the result that was actually observed, and what would have changed the decision. Separate what happened in the story from the lesson SOE is synthesizing from it.

Where a story makes a factual claim about a company, market or research finding, it should be supported by a named source before being treated as evidence. This page does not use an unattributed statistic as proof.

This is a documented case study. The source records attached to this article identify the public material used for the account. The lesson is a synthesis from those sources, not a claim that the same intervention will produce the same result elsewhere.