Day 8 · Real behaviour, clean paperwork, the market that pays

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

Four rooms, one lesson: design for how people actually behave. Vivek Verma on building around real daily routines, what an innovation ecosystem gives a hardware founder, Priya Darisini Sukumar on ESOPs, cap tables and data rooms, and a mentor on recurring revenue, moats and choosing the market that pays.

Week two of the Draper Founder Program started on a Monday that felt like four separate days stitched together. In the morning Vivek Verma, who ran the day's one-to-one sessions, held a prototype in his hand and explained, very kindly, that most of its size was unnecessary. Before lunch we walked through T-Hub and T-Works alongside a government delegation from Tamil Nadu. In the afternoon Priya Darisini Sukumar of Plough Back turned a "boring" session on cap tables, finance and compliance into the most uncomfortable, and most useful, two hours of the program so far. And in the late-afternoon pitch-and-guidance block, a mentor with decades of experience across Indian and American markets sat with Piyush and me over black coffee and asked the question every founder dreads: where does the money come from every month?

What connects the four is something I only saw when I sat down to write this. Every one of them was about designing for the real behaviour of people, not the behaviour we wish they had. Users who forget to charge things. Institutions that want to move faster than institutions usually move. Founders who promise "2%" on WhatsApp. Customers who believe they can build it themselves. This chapter is organised around those lessons, because they apply to any founder in any sector, whether you are shipping hardware, software or a service.

The day's programme

As announced to the cohort the night before:

• 9:30 am – 1:00 pm · One-to-one sessions with Vivek Verma
• 11:00 am – 12:30 pm · Scaling, team and product for every startup · Lakshmi Narayan Yeluri
• 2:00 – 3:00 pm · Cap table, finance and compliance for startups · Priya Darisini Sukumar (Plough Back)
• 3:00 – 4:00 pm · Pot painting, a deliberate breather in the middle of the day
• 4:00 – 7:00 pm · Pitch session and guidance with Ramjee Pallela

The campus walk through T-Hub and T-Works was not on the schedule; it happened around the morning one-to-ones. I have no notes from Lakshmi Narayan Yeluri's session on scaling, team and product, so it appears here only in the programme rather than with words I cannot stand behind.

Lesson 1: Design for the day your user actually has

The first conversation of the day was my one-to-one with Vivek Verma, who mentors a lot of startups in Hyderabad. I walked him through our wearable prototype, and he went straight to the thing I had been quietly avoiding: why is it this big?

I explained the history honestly, and it is a history many product teams will recognise. The very first version was tiny. It streamed everything to a phone or laptop, which did the real work. The problem was people. Phones disconnected, laptops went to sleep, and data was lost. So we added local storage and memory, and it grew. Then we wanted a longer battery so users would never have to think about charging, and it grew again. Every addition solved a real problem. Together they made a product that was heavier than anyone wanted to wear.

His reply reframed the problem. Computing is easy to fit in these days, he said. Battery is what eats your size. So cut it.

The one-day rule

His logic was simple:

• Nobody uses the device for 24 hours. They use it during specific working blocks.
• Add those blocks up and a typical day of real use is four to six hours.
• So six to ten hours of battery is more than enough. Aim for one day. Two days is the absolute ceiling.
• Anything beyond that (he laughed at the idea of seven days) is weight and volume with no benefit.

Then he said the part I keep thinking about. If a user only has to charge something every four days, they will forget, because it never becomes a routine. If they have to charge it every day, charging becomes a habit.

If he has to do every day, it becomes a habit. Every day I have charged it and every day I wear it. Those two things are very important.

• Vivek Verma, holding the prototype

When a feature is actually a bug

I had been treating a long battery as a feature. Vivek showed me it can be a bug: a bigger, heavier product that trains the user out of a routine. This is the general lesson, and it applies far beyond hardware. You do not ask the user to change their behaviour for your product. You design the product to ride on a behaviour they already have. Everyone already plugs in a phone every night; a device should sit next to it.

A few software versions of the same mistake:

• A weekly digest that nobody reads, when a daily two-line summary would become part of someone's morning.
• A "flexible" onboarding with twelve optional settings, when three defaults would get people to value faster.
• A monthly reporting feature for a team that makes decisions every Monday.

The question to ask of every spec is: which day is this designed for? If it is a day your user never has, you are paying for it in weight, cost or complexity.

Lesson 2: Show the output, not the object

Later in the morning, at T-Works, I showed the same prototype to one of the leads there. I explained what it does and how it filters out what does not matter. He listened and asked a very simple question: can you send me one sample, so I can see how a captured input is actually processed end to end?

That request was a small lesson in itself. I was talking about the device. He wanted to see the output, not the object. Every serious technical person, and most serious buyers, will ask the same thing. They do not want the tour of your architecture. They want to see what goes in, what comes out, and whether the thing that comes out is good.

So prepare one clean, consented, de-identified example that shows the full path from raw input to finished result. For a legal-tech tool that might be one contract, marked up. For an analytics product it might be one messy spreadsheet and the report it becomes. Keep it on your phone. You will use it more than your deck.

He also asked, with real curiosity, how a tiny team handles everything. My honest answer was that we lean on a wide network built over years of community work, we delegate wherever we can, and we try hard not to reinvent what already exists. That last part is underrated. A two-person team cannot afford to build anything that is not the core.

Lesson 3: Know what an ecosystem can give you

Late morning we joined a tour of the innovation campus that happened to coincide with a visit from Tamil Nadu's MSME minister and his team. It was a useful accident. I got to hear how Telangana pitches its ecosystem to another state, which is a very different pitch from the one a startup usually hears.

How a state tells its story

A senior Telangana official welcomed the delegation by talking about the shared history of the two states (the film industry that started in Madras came up, to smiles around the room), and then about skilling: modernising ITIs and polytechnics so that what academia teaches finally matches what industry needs. He mentioned Genome Valley for pharma, and then made a clear promise. Several states had already asked about a T-Hub "offshore facility" model, and Telangana would write a policy for it, with Tamil Nadu included from the start, and teams exchanged in both directions.

The T-Hub team then walked us through how the place works:

• A large building with separate floors for startups, investors, partners and the T-Hub team, plus event and launch spaces outsiders can use as long as the event is startup related.
• A network that scouts innovators from tier-2 and tier-3 districts through the state innovation cell and brings them into the hubs.
• An innovation centre on one floor focused on semiconductors, health, space and sustainability.
• Seats that are heavily subsidised compared with the market rate, which matters when you are a two-person team.

The line that stayed with me was about their structure. T-Hub described itself as government backed, not a government entity. Because it earns its own revenue from programmes and does not wait for approvals on every decision, it moves faster than a typical government body. For a founder, that distinction tells you which doors will open quickly and which will not.

The loop around the sensor

In one room they rotate products from incubated startups every quarter, depending on how well each is doing. Much of it was wearable health: a non-invasive glucose monitor that reads from a thumb sensor, a wearable ECG patch for people recovering from surgery that alerts doctors and family, a physiotherapy motion tracker that corrects posture as you move, an obstacle-detecting wearable for visually impaired people that vibrates more strongly as you get closer to something. There was also a coding kit for children built on games and paper puzzles, and a smart calculator that helps small shops keep track of daily transactions.

Seeing them side by side, I was struck by how little of the hard work in each was the sensor. It was the loop around the sensor: who gets notified, what the user does next, how it fits into a day. That is true of software too. The model or the algorithm is rarely the product. The loop is.

T-Works: where hardware stops being lonely

Then we crossed to T-Works, which introduces itself as India's largest prototyping centre. The film they showed listed 78,000 square feet, 80 advanced processes and 12 specialised labs under one roof: 5-axis CNC, multi-layer PCB fabrication, laser cutting, woodworking, ceramics, and a semiconductor partnership with Japan. A former airline pilot in the video described building a flight simulator there, because for once all the welding, fabrication and testing lived in one place, around the clock.

More interesting was how they described their role with MSMEs. T-Works does a lot of engineering in house, and wherever a job goes beyond its own machines, it plugs in an established MSME with that capability. So the startup, the manufacturer and the market sit in one ecosystem. They told us about a defence-tech summit in the same hall, where startups displayed their work in front of armed forces officers, fund houses and policy people on the same day. That is distribution, disguised as an event.

Reflection: use the ecosystem on purpose

My first startup was one of the early companies at T-Hub, years ago, and I burned my hands on it. Coming back now, I notice how much I did not use: the labs, the showcases, the introductions, the subsidised space. If you are near an ecosystem like this, in any city, make a list of what it offers and put a date against each. Most founders use ten percent of what is on offer and complain about the other ninety.

Lesson 4: Rules exist so both sides understand the same thing

The afternoon session on cap table, finance and compliance was run by Priya Darisini Sukumar, founder of Plough Back. A chartered accountant by qualification, Priya has spent close to two decades across a Big Four firm, a large Indian conglomerate and an independent consulting practice before starting Plough Back, a tech platform built out of that same advisory work. Priya looked at the mixed room, skipped the slides, and turned the session into an interactive, peer-to-peer exercise. It was the right call.

Around the table were founders building an operating system for short-stay property operators, a wearable camera with a voice interface, a security tool that protects organisations from rogue AI agents, and a media-management platform whose founder had deliberately not incorporated yet because he wanted to get the structure right first. That last choice set up the whole session.

Three digits and the case for rules

Priya opened with a puzzle on the whiteboard: using only three nines, what is the largest number you can write? The room gave different answers: 999, nine times nine times nine, nine to the power of 99, and more. The point was that even numbers, which we think of as unambiguous, produce different answers when no rules are specified. If that happens with three digits, it will certainly happen with a verbal promise or a loosely drafted contract. Rules and compliance exist so that both sides understand the same thing.

Priya also ran an anonymous poll. A large share of the room wanted to understand the numbers and the risks, and the most common answer to "who handles legal?" was "my CA or CS will handle it; I know the important stuff." The next two hours tested whether we did.

Red flag or green flag

Priya read out situations and asked us to call them:

• "Don't worry bro, 2% is yours." Promised to an early employee on WhatsApp. Red flag. Two percent of what? Equity or ESOP? Of issued capital or of the fully diluted cap table? Which class of share?
• "Just send the money, we'll call it a loan for now and sort out the terms later." Red flag. Undocumented money shows up in diligence as an unexplained credit, and nobody can tell what tax or conversion terms attach to it.
• A freelancer starting Monday with no contract. Red flag.
• "I signed the lease, the landlord wanted it today, I'll forward you a copy." Green flag, surprisingly. Forwarding and archiving every executed document is discipline, and that discipline later becomes your data room.

Then came the question of which of these would actually kill a funding round. The answer was one we had not even listed: a missing co-founder agreement. Of the 35 to 40 startups Priya has looked at closely, only four or five had one. Investors, even at the angel stage, will ask for it before they send the money.

First you avoid an awkward conversation. It's going to be more awkward later. The earlier you have it and you are done with it, the better.

• Priya Darisini Sukumar, on co-founder agreements

The best time to write that agreement is when nothing is wrong, because that is when it is easiest. When money and recognition arrive, unclear arrangements turn into conflict. I have seen it happen on a previous venture, and I suspect most people reading this have seen it too.

Offer terms you would accept yourself

Priya's advice on early hires went beyond paperwork. Ideas are everywhere now, and with AI, execution is getting faster too, so neither the idea nor the build is the moat any more. The moat is shifting to distribution, and at the earliest stage the best signal investors have of your ability to distribute is your team.

Or, as it was put to the room: if you are not able to convince one more person to come and join your team, how on earth are you going to get someone to pay for you? So be fair and be specific: offer terms you would accept if you were sitting on the other side of the table.

ESOPs are not what most founders think

This was the part of the session where the room went quiet and started taking notes. As Priya explained them, for Indian private companies:

• A pool is not real until it is filed. Creating an ESOP pool needs a board approval, then a shareholder approval, then a filing with the MCA. Priya described a well-funded client whose "ESOP pool" existed only in a spreadsheet. It had never been filed, so legally it did not exist, and investors ordered a full secretarial audit to find out what else was missing.
• Once the pool exists, grants can be simple. If the scheme gives the board power to decide allocations, you do not need a fresh meeting every time; resolutions can pass by circulation.
• The pool is notional until granted. It sits in the fully diluted cap table, not the actual one. Keep aside ten percent, grant one, and the other nine just sits there.
• Peg it to authorised capital. If you define the pool as a percentage of paid-up capital, it inflates every time you raise, and when investors object, the dilution comes out of the founders. Tie it to authorised capital, a fixed number, and it stays stable.
• You cannot discriminate. A scheme needs uniform eligibility criteria. You cannot hand-pick who gets to participate.
• Upfront equity and ESOPs are taxed very differently. An upfront shareholder pays tax only when they sell. An ESOP is treated as a perquisite, part of salary, so it is valued and TDS applies. A well-informed early employee will often ask for equity rather than options.
• Timing matters. Create the pool before an investor comes in and only the founders dilute for it. Investors know this and usually insist on it.

A compliance checklist nobody gives you at incorporation

Next came a list of "compliances", and we were asked to spot the fake ones. The real ones were more surprising:

• Issuing shares is a compliance, not an acknowledgement. You file a return of allotment (PAS-3) showing the price, the shares issued and your cap table before and after. Stamp duty on share certificates is also due in your state, including on the founders' own initial shares, and is very commonly missed.
• Your private company is not that private. Once you have filed a year of financials, anyone can pay a small fee on the MCA portal and see your shareholders, directors and paid-up capital.
• Appoint an auditor within 15 days of incorporation and inform the MCA. The first auditor holds office until the first AGM; after that, the appointment runs for five years.
• Hold the first board meeting within 30 days of incorporation. A common seal is optional for private companies, but if you adopt one, it is done there.
• GST registration never needs renewing. You only update it if your address or places of business change. Stop filing for months, though, and it can be cancelled.
• Letterheads and business cards are not compliances, but a signature pasted into PDFs and emailed around is a real risk. Anyone can reuse it.

Director loans and the one-card rule

A question from the room opened up a practical point. Most early founders pay company expenses from their personal account. If you transfer money into the company and spend it from there, it is a loan, and director loans need an annual disclosure (DPT-3). If you pay directly and the company reimburses you, it is a reimbursement. Either way, investors will later want proof of every rupee. The cleaner answer: keep one card used only for the company, so every transaction is already in one place.

Cap tables, convertibles and the 10% trick

Then a textbook exercise. Pre-money valuation of nine units; an investor brings one more. How much does the investor own? Half the room said 11.1% (one divided by nine). The answer is 10%. The price per share does not change when new money comes in; the number of shares does, so the denominator grows along with the numerator. It took several people at the whiteboard, and one groan of "I wish you were my maths teacher", before everyone saw it.

On instruments, as Priya explained them for India:

• CCPS sit inside your share capital, so your MoA must already allow two classes of shares. If it does not, you amend it first.
• CCDs sit outside as debentures and convert only on a trigger event, so no MoA change is needed.
• Convertible notes, the closest Indian cousin of a SAFE, carry the nature of debt, come with a maximum tenure and a minimum ticket size. Check the current rules with your CS before assuming a note is an option.
• Reverse vesting can apply to founders: shares are allotted up front but vest back over time or on milestones, and it should apply to every co-founder on the same principle.
• Contributing IP for shares is possible, but get an independent valuation of the IP rather than forcing a valuer to reach a number you already have in mind.

There was a warning about term sheets too. Founders sign them happily because they are "non-binding", then discover those exact terms walk straight into the shareholders' agreement.

A data room cannot manufacture a new fact or a new evidence. You're only going to archive it.

• Priya Darisini Sukumar, Plough Back

IP assignment, NDAs and the myth of the non-compete

"Your co-founder leaves after 18 months with half the code base. Who owns it?" The room tried NDAs, then non-competes. Priya's answer was blunt:

• An NDA only restricts disclosure. It does not transfer ownership of anything.
• A blanket non-compete is largely unenforceable in India because it conflicts with a person's right to earn a living. To have a chance, it must be specific and narrow, and you must compensate the person for the restricted period. Otherwise it is mostly a moral deterrent.
• The instrument that actually protects your code is an IP assignment agreement.
• Watch for moonlighting. If a new hire is still bound by a former employer's IP clause, what they build for you might belong to that employer, and nobody will care until you are big enough to be worth suing. During onboarding, read their previous contract's IP and confidentiality clauses.

Raise from strength

Someone asked how to influence valuation. At the early stage, Priya said, valuation is more art than science: a negotiation between two perceptions. With twelve months of runway you can walk away from a bad term. With twenty-five days, you will give away far more than you should just to make payroll. Always try to raise from a position of strength, Priya said, not from a position of desperation.

The cheapest incorporation is the most expensive

I asked about the single worst mistake Priya had seen. The answer was the story of a funded startup that had incorporated in a hurry through a cheap online service. The memorandum listed only industry codes and no actual main objects. When the investor wired the money, the bank refused the inward remittance and sent the funds back. The founders had to redo large parts of their incorporation documents within a week and wait weeks more for approvals. The session ended with a request to photograph the data-room folder structure on the screen and actually use it. We did.

Reflection: paperwork is behaviour, written down

The thread through the whole afternoon was that compliance is not a separate activity you do when funding arrives. Everything you do casually today, a WhatsApp promise, a personal card, an unfiled pool, is exactly what an investor will read later. The founder in the room who had not yet incorporated was not behind. He was ahead.

Lesson 5: Every model becomes an operations model

The last block of the day was the pitch session and guidance with Ramjee Pallela. Our slot in it turned into a long conversation with a mentor who has built companies in India, worked at one of India's earliest internet companies (back when e-commerce meant passing orders to a physical store and hoping they were fulfilled), and spent a long stretch in the US market. He started not with our product but with his own journey, because, as he put it, every entrepreneur goes through it.

His company began as a tech-enablement platform. Customer acquisition was expensive, so they needed a recurring model to recover that cost, which pushed them into recurring home services. Then they needed to train the workers, which pulled them into skilling programmes and a large training facility. Slowly they became a people management and logistics company, spending their days checking whether workers had been picked up, whether they reached on time, whether they had been trained. Eventually the model did not scale and they stopped.

He described how carefully they had studied the opportunity: people standing outside residential communities from morning to evening, counting how many domestic workers went in, how long they stayed, where they came from. The data was real. The problem was the gap between what looks obvious from outside and what the ground demands. They ended up in the middle between two parties, compensating for small damages to keep customers happy, arranging carpenters, scheduling autos across the city.

The lesson for any founder: before you choose a business model, ask what operations it will eventually force you to run. A marketplace becomes a trust-and-safety company. A delivery app becomes a fleet company. A hardware startup becomes a support and logistics company. Choose the one whose operations you can actually run.

Lesson 6: Know which market actually pays

He was direct about market structure. In the US, anyone with idle time and a car can drive for a ride-hailing app, and they do it happily. In India, supply is enormous, per-kilometre rates are low, and every driver complains about the commission. Almost everything in India has too much supply and too little willingness to pay. In the US, people pay for convenience; in India, customers have been trained to expect discounts and free delivery, and someone always absorbs that cost.

He had seen the same pattern in hardware pricing. In the US, a retail price around three times the bill of materials is normal. In India, you rarely get that multiple; distribution, margins and consumer marketing eat it, and customer acquisition stays stubbornly expensive.

That does not mean you should ignore India. It means you should know, with numbers, which of your markets pays for convenience and which pays only for necessity, and design your pricing and your channel for each.

Lesson 7: One conversation can hold several customers

When the mentor asked what our product actually does, Piyush explained it as only a doctor can, and it turned into a good worked example of a general idea. In a single consultation there are at least three parties who might care, for different reasons: the patient, the doctor and the hospital.

For the doctor, the value is less typing, inside the software they already use. For the patient, it is being able to recall later what the doctor actually said. For the hospital, the clearest return is fewer patients slipping away between a doctor advising admission and the admission actually happening. The same shape exists in most products. A school app has the student, the parent and the principal. An HR tool has the employee, the manager and the finance team. Map every party, then ask: who pays, who decides, and who can block you?

Only take what the right person said

One detail from Piyush's explanation generalises well. If a patient says they have a disease because they read about it online, a naive summariser will write it down as a diagnosis. That is a serious error. A good system records a claim only when the right person makes it. Any product that turns conversations into records (sales calls, interviews, legal meetings) needs the same discipline: who said it matters as much as what was said.

Lesson 8: Getting past "we can build it ourselves"

The mentor named the biggest problem in selling to large Indian institutions. You pitch a solution, they believe their internal team can build it in six months, and they rarely do, because it is never their top priority. Most founders selling to enterprises in any sector will recognise this.

Once you get scale, everybody will come on board. Our challenge is how do I get a foot in the door and scale to an extent where we become indispensable.

• A mentor

A few things that help, from the conversation:

• Ask what they tried before. If they attempted it internally, ask why it stopped. The answer usually tells you exactly which hard problem you must be visibly better at.
• Go through the software they already run. One partnership with a platform many customers use is easier than a hundred separate "we can build it" conversations. One organisation we met loved the idea but said, fairly, that after a decade on the same system they would not ask staff to learn a second one.
• Stay neutral. In any industry where data trust is everything, customers worry if someone closely tied to a competitor sits too close to your company. Be deliberate about who you bring into your inner circle.

Find the customer who decides fast

Then the mentor picked up something Piyush said almost in passing and suggested it might be the bigger market. Many specialists do not work in one place. A surgeon might operate at one hospital in the morning, consult at another in the afternoon, and see patients at their own clinic in the evening. For that person the value is continuity across every site. And unlike a large institution, an individual professional makes decisions quickly. Fix the right problem and they pay, without telling you they could build it themselves.

The general lesson: inside every slow enterprise market there is often a faster individual buyer. The freelance designer who works with five agencies. The consultant who serves three clients. Look for the person who carries your problem across organisations.

He also encouraged us to test an idea with a real buyer before building a plan around it, rather than falling in love with a channel on a whiteboard. That is the right order for any founder: validate, then plan.

Lesson 9: Stay two steps ahead, and stay narrow on purpose

He pushed us on defensibility. Hardware will increasingly be made by manufacturing partners, and everyone will catch up on the device. The value in the middle, the intelligence built from domain knowledge, is what you must make uniquely yours.

Yes, they will catch up with us the two steps. But I always want to be those two steps.

• A mentor

He floated a bolder idea, a product that would move into a regulated category. Piyush's answer was a useful counterweight. Crossing into regulated territory changes your company: one audit can end you. So there is wisdom in staying narrow deliberately, then adding small workflows that each save the user a minute or two. Before he left clinical practice, Piyush says, his whole target was simply: how can I save two minutes? Every sector has its regulated line (medical devices, financial advice, legal opinion). Know where yours is, and cross it on purpose or not at all.

Why domain experts must shape the product

He gave an example of why people who know the domain need to shape these products. Two lab test names that refer to the same liver enzyme were once treated by an engineering team as two different values and put into a ratio. That kind of error is invisible to an engineer and obvious to a clinician. Every industry has its equivalents, and they are exactly where a founder with domain depth wins.

Lesson 10: Argue your market question both ways

The mentor's strongest recommendation was to take the US seriously: more controlled working environments, documentation that is a legal requirement rather than a courtesy, much higher spend. In India, he warned, you might cap yourself at a limited number of large customers.

Piyush argued the other side. In the US, domain experts and engineers often train in the same universities, and competitors would appear within months. In India, domain-led products are rarer, which is a head start. Where we landed: India as the ground for product and data, the US as a serious scale market to prepare for, not a distraction to chase today. The debate is not over, and that is fine. What matters is that you argue it with evidence on both sides instead of defaulting to whichever market feels more exciting.

Lesson 11: Investors invest in people

Near the end he said the thing I most needed to hear. Investors invest in people. They want you to be passionate, they know you might fail, and your assumptions about market size, pricing and even the product itself will all be tested. His practical advice was to apply to the best global accelerators you can find, whether or not you get in, simply for the quality of the questions you will face.

The deck is not the pitch

One small thing about that block surprised me. It was billed as a pitch session, and we never opened the deck. At one point Piyush checked: had the mentor even seen our pitch deck? No. We had simply had a conversation. His view was that what he was really judging was how connected you are to the problem, how much it means to you to get it right, and whether you can talk about your assumptions honestly while they are still being tested. A deck is useful to have. It is rarely what decides the room.

You are going to go through highs and lows in this. You will learn along the way. Your assumptions will be tested along the way.

• A mentor, in the pitch-and-guidance session

He also noticed how Piyush and I work together. We disagree often, but we come back with evidence, not opinions. Piyush's rule for me is simple: he is the first customer, and if he is not convinced, no user will be. That is a rule any co-founding pair can adopt: one of you plays the sceptical customer, every time. The mentor smiled and said the market would teach both of us patience. I am the impatient one. I am working on it.

Reflection: the same lesson in four rooms

Looking back, the four sessions were one lesson told four ways:

1. Vivek Verma's one-to-one: design around the user's real day, not an imagined one.
2. T-Hub and T-Works: the hard part is rarely the part; it is the loop and the ecosystem around it.
3. Priya Darisini Sukumar's session: what you do casually today is what an investor reads later.
4. The pitch-and-guidance block: every model becomes an operations model; choose one you can run, in a market that will pay.

Apply it to your startup

• Hardware or software, audit the day. List the hours your user actually touches your product. Cut anything built for a day they never have.
• Carry one perfect sample. Input in, output out, consented and de-identified. Show it before the deck.
• Map your ecosystem. Write down every lab, showcase, subsidy and introduction available within an hour of you, and use three of them this month.
• Do the compliance sweep now, not when a term sheet arrives: co-founder agreement, share allotment filings and stamp duty, auditor, first board meeting, any promise living only in a chat or a spreadsheet.
• Name your operations future. Write one sentence: "If this works, we become a ___ company." If you would hate running that, change the model now.
• Find your fast buyer. Inside your slow market, who carries the problem across organisations and can decide alone?

Resources from the day

People who taught

• Vivek Verma, one-to-one sessions: designing around the user's real day.
• Lakshmi Narayan Yeluri, session on scaling, team and product for every startup (listed in the programme; no notes from me).
• Priya Darisini Sukumar, Plough Back, cap table, finance and compliance for startups.
• Ramjee Pallela, pitch session and guidance, the block in which our long mentor conversation took place.

Frameworks and exercises worth reusing

• The one-day rule, and "output, not object" (one end-to-end sample).
• The three-nines puzzle and the red flag or green flag drill.
• "2% of what?", and the three-step ESOP pool (board, shareholders, MCA filing).
• The early-company compliance list (PAS-3 and stamp duty, auditor, first board meeting, DPT-3, GST).
• The pre-money and post-money exercise; CCPS, CCDs and convertible notes compared.
• NDA versus non-compete versus IP assignment agreement.
• The data-room folder structure.
• "If this works, we become a ___ company", and the user, buyer, institution map.

Places and tools mentioned

• T-Hub and T-Works, Hyderabad; the MCA portal for public company records; one company-only card for every expense.

What to take away

• Design for the day your user actually has. A short daily loop beats a long gap nobody remembers.
• Show the output, not the object. One end-to-end sample beats a tour of your architecture.
• Use the ecosystem on purpose. Most founders use a tenth of what is on offer.
• Rules make both sides mean the same thing. "2% of what?" is a question you should answer before anyone asks.
• Write the co-founder agreement while everything is good. It only gets more awkward.
• An ESOP pool is real only when filed. Peg it to authorised capital, create it before investors arrive.
• One card for the company. Every rupee, already in one place.
• A data room only archives. It cannot manufacture a fact you did not create on day one.
• Raise from strength. Runway is negotiating power.
• Every model becomes an operations model. Choose the operations you can run.
• Stay two steps ahead, and narrow on purpose.
• The deck is not the pitch. People judge how connected you are to the problem.

Try this

1. The real-day audit. Write down, hour by hour, when your user actually touches your product on a normal day. Now look at your spec (battery, storage, session length, notification frequency, pricing tier). Which features exist for a day your user never has? Cut one.
2. Red flag inventory. List every promise you have made about equity, loans, freelancers or partnerships. Next to each, write: documented, signed, archived? Anything without all three is a red flag you have chosen to keep. Fix the top two this week.
3. The "2% of what" test. For every equity or ESOP number you have mentioned to anyone, complete this sentence: "__% of [issued / fully diluted] capital, as [equity / ESOP / note], vesting over __, with [these] rights." If you cannot finish it, neither can they.
4. Build the data room today. Create folders for incorporation documents, cap table, board and shareholder resolutions, agreements, MCA filings, GST and TDS, and financials. Put in what you have. The empty folders are your compliance to-do list.
5. Several customers in one interaction. Draw every party who touches one use of your product. Mark which one pays, which one decides and which one can block you. If one person does all three, you have found your easiest door.
6. Two steps ahead. Write down what a well-funded competitor could copy in six months. Then write the two things you will have by then that they will not. If you cannot name them, that is next quarter's roadmap.