June 5, 2026·6 min read

How can I figure out who my real customers are from my product code?

TL;DR

You can find your ideal customers from your codebase because the product you built is a map of who you built it for.
Dependencies and integrations reveal how technically sophisticated your user is.
Architecture and data models reveal the real use case and how central the product is to someone's day.
The features you built first usually point to the most acute pain, which is the angle you should lead with.

---

Your code is a record of decisions about a user

Every choice in your repo was made for someone. When you decided to add team roles, billing, or a particular integration, you were imagining a person who needed it.

That makes your codebase a quiet record of your assumptions about your customer. You can find your ideal customers from your codebase by reading those assumptions back out.

This matters because most founders define their customer vaguely, as "anyone who needs this." The code is more specific than the founder, because it had to make real choices.

You are not inventing an ICP from nothing. You are recovering one you already encoded without noticing.

Dependencies reveal sophistication

Look at what your product is built on and what it connects to. The integrations tell you who the user is.

A product wired to Stripe billing, role based access, audit logs, and an admin panel is built for paying businesses with teams. That user is sophisticated, expects reliability, and will evaluate you seriously.

A product built around a single simple input and a clean output, with no accounts at all, is built for a casual individual user. That person wants speed and simplicity and will leave the instant it gets complicated.

The integrations are an especially strong signal. If you integrate with Slack, Notion, and Linear, your user lives in those tools, which means they are a knowledge worker at a startup or tech company. If you integrate with QuickBooks and a CRM, your user runs a small business.

Read your dependency list as a description of a person's working life. It is more accurate than most surveys.

Architecture reveals the use case

How your product is structured tells you how it is used.

A product with a heavy scheduling layer, background jobs, and notifications is something people rely on continuously, often without opening it. That is infrastructure, and the user cares about it never failing.

A product that is one focused screen the user visits to complete a single task is a tool, not infrastructure. The user shows up, does the thing, and leaves. They care about speed and clarity.

Your data model is especially revealing. The central entity in your database is usually the central thing in your customer's world. If everything hangs off "campaign," you serve marketers. If everything hangs off "patient," you serve clinics.

Trace your schema to its core table. Whatever that table represents is what your customer organizes their work around.

Early features point to the acute pain

The order in which you built things is a clue. What you built first is usually what hurt most.

Founders build the painful thing first, because that is the pain that drove them to start. The earliest, most polished feature is often the core wound your product treats.

Find that feature and describe the problem it removes in plain language. That description is your lead message, the acute pain you put at the front of every pitch.

The features you added later are supporting. They round out the product, but they are not what makes someone switch. Lead with the first thing, not the latest thing.

Turning the reading into an ICP

Put the three readings together and you have a profile.

Sophistication, from your dependencies and integrations: is this a casual individual, a technical pro, or a business team
Use case, from your architecture and data model: is this infrastructure they depend on or a tool they visit
Acute pain, from your earliest feature: what specific problem drove the build

Write these as a description of one person. "A startup operations lead who lives in Slack and Notion and relies on this to stop X from slipping through the cracks."

That sentence tells you where to find them, the communities around startup operations and those tools, and what to say, the pain you built first. You got all of it from the repo.

Why this beats guessing

Most ICP exercises are guesswork dressed up as strategy. Founders imagine a customer they wish they had.

Reading the codebase grounds the profile in what you actually built. It catches the gap between the customer you say you want and the one your product is genuinely for.

Sometimes that gap is the real insight. You set out to build for beginners but every architectural choice points at experts. The code tells the truth, and the truth is where distribution should aim.

Start with the repo. It already knows more about your customer than your pitch deck does.

---

Frequently Asked Questions

Can my codebase really tell me who my ideal customer is? Yes, because every dependency, architectural choice, and early feature was a decision made for a specific kind of user. Reading those choices back out gives you a profile grounded in what you actually built rather than in who you wish you were serving.

What do my dependencies say about my customer? Your dependencies and integrations reveal how technically sophisticated your user is and what tools they already live in. Integrations with Slack, Notion, and Linear point to startup knowledge workers, while billing, roles, and audit logs point to paying business teams.

How does my product architecture indicate the use case? Architecture shows whether your product is infrastructure people depend on continuously or a tool they visit to complete a single task. The central table in your data model usually represents the central thing in your customer's world, which tells you what they organize their work around.

What if the customer my code points to is not who I expected? That gap is often the most valuable finding, because the code reflects the choices you actually made rather than your assumptions. When your architecture consistently points at a different user than your pitch, the code is usually closer to the truth and should guide where you aim distribution.

---

Vibs.io reads your GitHub repo or product URL and turns it into a concrete ideal customer profile with the communities attached: see it at [vibs.io](https://vibs.io).

Start distributing your product →