Day 7 · People, plumbing and pilots that tell the truth

By Karthik Nagapuri · 2026-09-20 · Draper Founder Program #2

A long Sunday of founder lessons: hiring without money or brand, making the first yes cheap, surviving a vanished investor, setting up a US entity the right way on day one, and designing pilots that show whether users will really keep using what you built.

The program does not take Sundays off, and honestly most founders do not either. Day 7 started with a circle of founders at breakfast time and ended close to 3 a.m. with my co-founder Piyush and me sketching screens on paper. In between there was a founder who told the truest version of "how it actually went" I have heard in a while, a legal and tax session I wish someone had given me three years ago, a product demo inside a working hospital, and an evening of superhero pitch videos. This chapter is long because the day was long. I have organised it around the lessons, because every one of them applies whether you are building drones, software for property managers or a consumer app, and whether you are a student with an idea or an operator about to quit your job.

The morning circle: everyone fights the same battles

We began with a round of introductions. The range in the room was wide: glasses with an interpretable machine-learning model that let people with disabilities authenticate and pay without touching anything, an autonomous drone an infantry soldier can take out of a backpack and throw into the air, a platform that automates the manual grind of property management, a market-signal engine that watches a company for weeks before telling a sales team when to call, a camera-based wearable that can see and talk back, and a system of record for media teams.

I love these circles because you realise quickly that everyone is fighting the same battles in different uniforms. Talent. The first customer. The day the money does not come. So the host asked the same three questions of a founder who has been building defence electronics since 2017, and his answers became the spine of the morning. I am writing them down almost in full, because they work as a small operating manual for any early company.

Lesson 1: Hire hunger, train it, keep it

His first point was that talent starts before hiring. You need a co-founder who can genuinely share responsibility, because everything after that depends on it. Then he was frank about the position a young company is in: no money, no customers, no brand. When you ask a good engineer to leave a stable job for that, most will hesitate, and you cannot afford the best of the market anyway.

So what did they do?

• They hired people who were not from famous colleges and had no previous work experience, but who were hungry to learn.
• They leaned on interns: hire, train and keep them. Those interns turned out to be more invested in the work than lateral hires, because they liked the company and what it was building.
• Several of those early interns are now middle managers, each leading a team of their own.
• Some roles still sit open for six to eight months. Talent is never "solved", it is managed.
• His advice to the room: start with your juniors and college friends. That is where trust already exists.

So they are real assets. The people are the real estate for the company.

• A defence-tech founder, answering the talent question

Reflection: what "hungry" actually looks like

It is easy to nod along to "hire hungry people" and then interview for polish anyway. What I took from his story is that hunger shows up as behaviour you can test for: did they build something nobody asked them to, did they come back with questions after the first conversation, do they stay curious when the work is boring. A first-time founder with no brand is not competing for the same people as a large company. You are competing for the people who want to learn fastest. Design your hiring around that and the "no money" problem becomes smaller.

Lesson 2: Make the first yes cheap

The second question was how you find your first customer in a domain where trust is everything. His answer was about stakes. People take a risk on a startup when the consequence of failure is small. In a large organisation it is not the buyer's own money, so nobody wants to be the person who backed the unknown vendor that failed. You cannot walk in on day one and ask for a large order. You start with something small enough that saying yes is easy, deliver it, and let the relationship grow. In defence especially, he said, you have to start small every year.

This is true far beyond defence. The person who signs off on a new tool, whether in a hospital, a bank or a school, is carrying the risk personally. Your job is not to convince them that your product is amazing. It is to design a first order that makes saying yes feel safe.

A few ways to shrink the first yes, from the conversation and from what I have seen since:

• A paid pilot scoped to one team, one site or one workflow.
• A fixed, short timeline with a clear success metric agreed in advance.
• A way out that costs the buyer nothing if it does not work.
• Something they can show their own boss after thirty days.

Lesson 3: When the promised money disappears

The last question was about a defining moment, and his story was the one I will remember from the whole day. Early on, they had chosen an investor who promised to fund them in monthly instalments over eighteen months. They had a roadmap, product ideas, plans for multiple products. Four months in, the investor said he could not put in any more money.

Overnight they had nothing: no revenue, no paying customer, rent and salaries due. They gave up the office and worked from wherever they could until they found a very small place. Then they did the thing I respect most. They sat the team down and told them the truth: this is the situation, we are not getting that money, so we are putting the product roadmap aside and working on whatever brings in revenue now.

He said the most painful part was not the customers. It was answering the worried families of young employees, who wanted to know whether this company was a safe place for their child's future. The company recovered in three or four months. He described it simply as the test that made them.

Reflection: a promise is not a balance

There is a quiet warning in that story for every founder who treats a promised cheque as money in the bank. Until it clears, plan as if it will not. And notice the order of his three answers: people first, then small bets with customers, then honesty when it breaks. None of it is clever. All of it is hard. If you only remember one line from the morning, make it this: the truth, told early, keeps the team.

Lesson 4: Get your structure right before money moves

The second session was with Nitin, co-founder at Finstack and an alumnus of the previous cohort. Finstack does the back office for businesses in the US: incorporation, accounting, bookkeeping, payroll, taxes, diligence support and compliance. His reason for building it was lovely in its honesty: he is a non-tech, non-finance founder who never understood tax, and he wanted one platform and one team instead of juggling five vendors.

A detour: your body is a booth

Before the legal part, he shared one growth trick that worked for them. When you are too early to afford a booth at a big conference, the only physical asset you have there is yourself, and you have already paid for the ticket. So he wears a T-shirt that does the selling. He calls it moving real estate. He wore one at a large AI conference in the US and it started conversations a booth never would have. It is exactly the kind of scrappy thing a founder can do without asking anyone's permission, and it costs less than a coffee meeting.

Why have a US entity at all?

He gave three reasons, and said you need at least one of them:

1. You have a paying customer or a real market in the US. Invoicing as an American entity simply makes life easier for the buyer.
2. You want to raise from US investors. A large share of AI capital sits in and around San Francisco.
3. You are building for the world and want a parent company in a jurisdiction that makes it easy to open subsidiaries elsewhere later.

If none of these is true for you yet, you probably do not need one yet. That alone is worth knowing before you pay anyone.

India parent or US parent?

This depends on two things: where your business is, and where your funding comes from.

• If your market and your funding are mostly in India, and the US is mainly for selling, an Indian parent with a US subsidiary is fine.
• If you plan to raise from US VCs, he was blunt: almost every time, they will expect a US parent with an Indian subsidiary. It is possible to convince a US investor to back an Indian parent, but he called that a one-in-a-hundred case.

On where to incorporate, Delaware is still the default for an Indian founder, with a C-Corp as the usual form. Texas and Nevada are picking up, but Delaware remains the one investors recognise.

The plumbing, step by step

He drew it on a tablet (after a small fight with the pen, which prompted someone in the room to mutter "user experience"). Here is the version I copied down.

A US entity as a subsidiary of your Indian company:

1. Your Indian private limited company already exists.
2. Incorporate the US entity. Choose the name, register it, get an EIN (the US equivalent of a PAN), open a bank account online with an e-KYC. Without anyone holding an SSN, it takes roughly ten days to four weeks.
3. Complete the ODI, Overseas Direct Investment. This is the step people skip.

Why ODI matters: the moment your US entity is formed it is, in his words, an orphan. It has your names on the paperwork, but India does not recognise it as owned by your Indian company. To create that relationship, the initial share capital has to move from the Indian company's bank account to the US company's account, with the RBI informed under FEMA that this is an investment in a foreign subsidiary.

You set it up on day one and finish this in the first few months, you're good. The cost of doing this later becomes expensive.

• Nitin, Finstack

The reason is valuation. On day one you transfer a tiny share capital at face value. Later, you have to value the company as it is that day and transfer that amount to establish the relationship, which is money no early startup has. ODI itself takes four to eight weeks, often because bankers are nervous about the RBI. But it does not stop you operating the US entity in the meantime.

A US parent with an Indian subsidiary (the "flip"):

1. Each Indian founder sets up a personal LLP. Indian rules do not let an individual directly own a foreign company that in turn owns an Indian subsidiary, so the LLP becomes the vehicle for your shareholding.
2. Incorporate the US entity.
3. Complete the ODI, with the LLP transferring the founder's share of capital to the US company.
4. The US company then invests into the Indian private limited company through FDI, again informing the RBI, so the US parent owns the Indian subsidiary.

His own company was the example: his US co-founders transferred their share directly, and he, as an Indian resident, went through an LLP. The LLP, he explained, only matters when dividends or an exit happen. Day to day, he works in and for the Indian subsidiary.

Small things that trip founders up

• Registered agent versus virtual office. A registered agent is mandatory: it is the official address where the state sends legal communication. A virtual office is optional, only for a US mailing address on invoices. People confuse the two and pay for the wrong one.
• Nexus. Every time you start doing real business in a new state (an office, a hire, meaningful revenue), you may need to register there. The paperwork is easy; tracking the taxes is the hard part.
• Tax is on profit, not revenue. He kept hearing "if I do a million in revenue, how much tax do I pay?" You could have that revenue and pay nothing if you made a loss. Federal plus state corporate tax comes to roughly thirty percent, and the India-US treaty stops you being taxed twice on the same income.
• IP follows the relationship. Once the group structure is set up correctly, what the US entity owns sits within the group, so you do not have to agonise over which country "holds" a patent.
• You do not need a local. No US partner, resident director or big bank relationship is needed to set up a Delaware entity.
• Know your co-founders' situation. US co-founders may be eligible for tax benefits on startup gains that Indian residents are not. Most founders do not know such differences exist until an exit.

His closing advice sounded boring and is the kind that saves you later: choose your structure early, spend real time on your long-term plan, and get it right before money starts moving. The cost looks big to a startup today and tiny against what it avoids.

Reflection: structure is a product decision

I used to think of company structure as something your CA handles after the real work. Nitin's session changed that. Where your parent sits decides who can invest in you, how easily you can sell abroad, and how painful your first diligence will be. It is a product decision about your company, and like most product decisions it is cheapest to get right early.

Lesson 5: Be useful first, then tell the story

After Nitin's session the conversation drifted, and someone retold a story from an earlier program challenge where teams had to sell flowers at the airport. Our team bartered its way into a bouquet and sold the stems one by one. The best sale came from a woman who could not find her cab. We walked her to the pickup point, pushed her trolley, and only then told her what we were building. She bought a flower for far more than any florist would charge.

The lesson was not about flowers. It was that people respond to who they perceive you are. Be useful first. Then tell the story. It is the most transferable sales lesson I know, and it works for enterprise deals as well as it works at an airport kerb.

Lesson 6: Put the product in the real room

In the afternoon Piyush and I took our own product into a working hospital, Himagiri Hospital, where we have been sitting beside doctors and iterating with their feedback. I will use it as the worked example for this lesson, because what happened there is what happens to every product the first time it meets a real user in a real environment. A senior surgeon tried it, with a mentor who advises us sitting in. Both stay anonymous; the lessons are what matter.

Users will find use cases you missed

The surgeon understood the product properly within about forty-five minutes, and then found a use case of his own. We had been thinking only about the outpatient consultation. He pointed out that surgeons record videos of operations to teach juniors but cannot narrate while operating. A small wearable could capture the commentary in real time. We had been thinking about one room, and he found another.

The general lesson: your first serious users are also your best product strategists. Leave room in every demo for them to tell you what else it could do, and write it down even if you will not build it this year.

The output is the product

His feedback was direct, and every point generalises:

• Judge by the end result. He cared about what came out at the end of the consultation. Everything in the middle was secondary. Your user judges you on the artefact they walk away with, not the clever steps in between.
• Kill steps. We had built drag-and-drop editing on the review screen. He did not want it. Click to confirm, move on. Every interaction you add is a small tax.
• Show structure, not a wall. Separating who said what made the output instantly trustworthy. Structure is how users verify.
• Finish with a single action. The last screen should be ready to sign and done.

Build for the device already on the desk

One observation came from the building itself. Many consultation tables at the hospital do not have computers, and buying hardware for every desk is a real cost for any organisation. We had been debating which desktop platforms to support. The answer was sitting on the table: the phone they already carry. Before you choose a platform, walk into the place your user works and look at what is physically there.

Privacy is the gate, not a feature

The mentor pushed hard on data. If a user tells you something deeply personal and it travels to a third party's cloud, that is a reason for any institution to say no. The principles apply to any product that touches sensitive information:

• Raw data should leave the device only when there is no other way.
• Strip identifying details before anything goes to a server.
• Keep only what you need, and throw the rest away.

Plug into what they already use

The strategic point, which kept coming up all week, was simple: do not build yet another system your customer has to learn. Plug into the software they already use. Then the software vendor earns more, the customer gets more, and you get distribution. A fintech founder might apply this by living inside the accounting tool a small business already opens every day, rather than asking them to open a new dashboard.

Lesson 7: It is not yet time to sell

We had been talking a lot about leads, partners and investors. The mentor stopped us. His message, delivered in a mix of Hindi and English, was that this was not the moment to sell. It was the moment to build.

His prescription was concrete, and I think it is right for almost every early startup:

• Get a handful of real users using the product consistently, every day, and getting clear value from it.
• Until that happens, stop chasing new leads.
• Fix the core experience and the accuracy first.
• Revise the product in front of the same users, again and again, and show them each new version.
• Make a priority list and follow it.

The trap he was pointing at is familiar. Selling feels like progress because it produces meetings, and meetings feel like momentum. But a hundred warm leads for a product nobody uses daily is a liability: every one of them will try it too early.

Let your advisors inside the circle

He also said something about advisors that I want to remember for when I am on the other side of the table. An advisor kept outside the circle cannot help. He described it as seeing the circle from every angle only if you are allowed to stand in the middle of it. If you want someone's direction, let them see the whole picture, including the uncomfortable parts. Otherwise all they can do is react to the story you tell them.

Lesson 8: Build for your own pain first

By evening the whole cohort was upstairs and the mood was lighter. A peer asked to see Sudoor, a developer tool I built for myself over about eight months, bit by bit, whenever something annoyed me enough. When you have many coding sessions running at once, you forget where your workspaces are, how much you are spending on tools, what your network is doing. Sudoor pulls it into one place next to the terminal: workspaces that open ready for an AI coding agent, a spend tracker, a network check, a clipboard history, a research feed, and a water reminder, because I forget.

When asked how long it would take to rebuild from scratch, my honest answer was three days to a week. It grew over months because I kept adding what was missing. The point of showing it was not the tool. It was that build for your own pain first is still the fastest way to learn what a product needs, because the user is always in the room.

Lesson 9: Pitch what happens after you get hit

The cohort had been asked to make short superhero-themed pitch videos, and we watched them together. One founder in defence opened with a line that got a laugh of recognition from the whole room.

Every founder has a dirty, messy prototype. Captain America had vibranium.

• A cohort founder, in their superhero pitch video

Another founder had drawn Wolverine and turned it into the line I wrote down immediately.

I don't think it's really about the claws. It's about what happens after you get hit.

• A cohort founder, in their superhero pitch video

He followed it with "You don't always get the problem you started with. You adapt." That is a good description of the whole morning's defence founder too. Investors and customers are not really buying your prototype. They are buying evidence of how you respond when it breaks.

The only feedback on the first video was that the background music was drowning out the words, which is, to be fair, the most common problem in every pitch video ever made. If you make one: words first, music at half the volume you think.

Lesson 10: Decide who keeps the customer

Later that night I walked a peer through how a small company can work with a much larger software partner. Stripped of our specifics, the model is worth writing down for anyone building a component that lives inside someone else's product:

• The partner keeps the customer relationship, billing and first-line support.
• You handle the specialised part you are genuinely better at, and support it in the field.
• The partner sends you the context you need; you send back a structured result they can use directly.
• A pilot runs for a fixed window, and early on you place one engineer close to the partner to learn their system.

A useful insight from the conversation: large companies often do not want to touch the messy parts (hardware, imports, warranties, field support). That is exactly why they need a partner who will. And for partners who want less, you can expose the same value through an API or SDK.

We also talked about staying vertical. The same technology could serve many industries, but domain focus is what makes it good. Knowing which parts of your user's world matter and which are noise is the product.

Lesson 11: Design a pilot that tells the truth

The last recording of the day started at around a quarter past three in the morning. Piyush and I sat down to turn the afternoon's advice into a plan, and the principles we landed on apply to any pilot.

Software first, delight second

A proof of concept shows that the thing works. A pilot has to show that people keep using it. Those are different questions. So our plan puts the simplest version (an app) in everyone's hands, and gives the more delightful version (a hardware prototype) only to the keenest users. The reluctant ones get the plain version, so you can see whether they use it without the novelty. Be honest with everyone about what a prototype is and is not.

Solve the common problem across segments

Reach users across every level or segment, because their workloads differ completely. In a hospital that means interns to heads of department; in a company it might be analysts to managers to directors. You are not solving one level's problem. You are solving the common problem that shows up across all of them.

Expect one in five

Be realistic about the ratio. Out of every five people you approach, expect one to give you real feedback. People forget to switch it on. They forget to charge it. It stays at home. So the job is to follow up every day, in person if possible, with the simplest possible question. Piyush's version, for doctors, was "Sir, aaj kya kiya?" (Sir, what did you do with it today?)

The output of a good pilot is a single document: what you heard, from whom, at which level, and the common problems. That document becomes:

• your first real feature set, built from users' words rather than your assumptions,
• your go-to-market proof when someone asks "how many users did you speak to?",
• testimonials in users' own voices, with permission,
• the material you share with partners to show the product is built on research.

Do not burn well-connected users

Piyush passed on a warning he had heard from a senior doctor: you only get one chance with a well-connected user. If the demo fails, that person tells ten others. In any tight professional community (doctors, lawyers, school principals, CFOs) reputation travels faster than your product. Hold back your best connections until the product is ready for them.

Privacy by design, even in a pilot

Even for a small pilot, decide what you will not keep. Our rule: do not store raw recordings, anonymise locally before anything goes to the cloud, and keep only the structured result. The equivalent for your product is whatever data would embarrass you in a headline.

Screenshot, not code

One small process lesson for me. I had built reference screens as working HTML because I like to deliver things production-ready. Piyush pointed out that they were useless on the platform we were actually building for, and a waste of my time. For references, send a screenshot with notes drawn on paper. Save the effort for the real build.

Apply it to your startup

Here is how I would use this day if I were starting from scratch in any sector.

• If you are pre-team: write down the five people who would join you for the work, not the salary. If you cannot name five, your first job is building a network of juniors, classmates and interns, not a job post.
• If you are pre-customer: design your smallest possible first order. What could a buyer say yes to without risking their own reputation?
• If you are waiting on money: plan the next ninety days as if it will not come. Write the honest speech to your team now, while you do not need it.
• If you might sell abroad or raise abroad: decide your parent company question this quarter, and do the ODI while your share capital is still tiny.
• If you have a working prototype: stop selling for two weeks. Get a handful of users using it daily, and follow up every day.
• If you are building a component: decide who keeps the customer, and make that the first line of every partnership conversation.

Resources from the day

People who taught

• Nitin, co-founder of Finstack and an alumnus of the previous cohort: US entities for Indian founders, ODI, the flip, and the small print that trips founders up.
• A defence-tech founder in the morning circle (kept anonymous here), on talent, first customers and surviving a vanished investor.

Frameworks and checklists worth reusing

• The morning's three questions: how you attract your first people without money or brand, how you win a first customer where trust is everything, and what your defining moment taught you.
• Hire, train, keep: interns and juniors as the first team.
• The small-ask ladder: small ask, safe yes, deliver, bigger ask.
• Three reasons to have a US entity (a US market, US investors, a global parent), and the India-parent versus US-parent decision.
• The flip, step by step: Indian private limited company, Delaware C-Corp, ODI, founder LLP, FDI into the Indian subsidiary.
• Registered agent versus virtual office; nexus; tax on profit, not revenue; the India–US tax treaty.
• Output is the product: judge by the end result, kill steps, show structure, finish with one action.
• The pilot that tells the truth: software first and hardware as delight, users across every level, expect one in five, one learning document with four uses.
• Screenshot with pen notes, not coded mockups, for reference screens.

Terms and tools mentioned

• EIN, ODI, FDI, FEMA and the RBI, Delaware C-Corp, founder LLP.
• The superhero pitch-video format the cohort used, with one rule: words first, music low.
• Sudoor, the developer tool I built for my own workflow.

What to take away

• People first, stakes small, truth always. The defence founder's three answers are a whole operating manual.
• Hire hunger. No brand means you compete for the people who want to learn fastest.
• Make the first yes cheap. Shrink the buyer's personal risk before you grow the order.
• A promised cheque is not money. Plan as if it will not arrive until it does.
• Structure early. Parent company, ODI, founder LLP: ten boring days now or a painful month during diligence later.
• Be useful first. People respond to who they perceive you are.
• The output is the product. Users judge you on what they walk away with.
• Not yet time to sell. A handful of daily users beats a hundred warm leads.
• Let advisors in. They can only help with the picture you let them see.
• Pilots test habits, not features. Expect one in five, follow up daily, write one document.

Try this

1. The three questions. Answer the morning's questions for your own company in writing: How will you attract your first five people without money or brand? What is the smallest first order a customer could say yes to without personal risk? If your expected money did not arrive tomorrow, what would you tell your team on Monday?
2. Your entity map. Draw your current structure in boxes and arrows. Mark every relationship that is not yet formalised (ODI, FDI, founder shareholding, IP ownership). Write the date you will fix each one, and the name of the person who will help you.
3. The one-in-five sheet. List every user you plan to reach in your pilot, by seniority or segment. Next to each, write how you will follow up daily and what "real feedback" means. Assume only one in five will give it, and plan your outreach numbers accordingly.
4. Kill a step. Walk through your product's main flow and count the taps or clicks. Remove one screen or one interaction this week, and watch whether anyone misses it.
5. Where does the raw data go? For one user action, trace exactly where the raw data travels and where it is stored. If it leaves the device or your control before it is anonymised, redesign that step.
6. Useful first. In your next five sales or partnership conversations, do one genuinely useful thing for the other person before you mention your product. Note which conversations went further.