FOUNDER’S OFFICE · OPERATIONS · FINANCE · SYSTEMS

I turn the work stuck in a founder’s head into a system the team can run.

I’m Sparsh—an Economics Honours graduate, CFA Level I cleared, and startup operator. I like the problems with no clean owner: understand the mess, build the answer, and hand bandwidth back to the team.

HOW I CREATE LEVERAGE
STARTAmbiguous
problem
01FrameWhat decision is blocked?
02MapWhat data and constraints matter?
03BuildWhat system will people use?
04ImproveWhat did the real workflow teach us?
REPEATABLE OPERATING LOOP
OUTCOMEClearer decision+Less manual work+More founder bandwidth
SCROLL
BACKGROUNDEconomics Honours
CFA Level I cleared
CURIOSITYAI, technology &
how startups work
OUTSIDE WORKFootball, building,
asking too many questions

I want to build something of my own one day. That makes me naturally curious about the full business—not just the task in front of me.

Start with the decision.
Build only what creates leverage.

I do not begin with “Which tool should we use?” I begin with the team’s actual bottleneck and work backwards.

01
?

Frame the decision

Turn a vague request into one clear question: who needs to decide what, and what is stopping them?

OUTPUT · CLEAR PROBLEM
02

Map the real system

Bring together the data, customer context, constraints, edge cases, and people the request touches.

OUTPUT · SHARED CONTEXT
03

Ship the useful version

Build the smallest model, tracker, workflow, or internal tool that improves the decision now.

OUTPUT · WORKING SYSTEM
04

Learn from usage

Watch the system operate, fix what breaks, and automate the next proven bottleneck.

OUTPUT · COMPOUNDING LEVERAGE

Operating systems built inside a live mobility business.

FIRST, THE BUSINESS CONTEXT

Pluto is a Bengaluru subscription commute startup. Customers pre-book recurring office rides. The business works when seats stay full, routes stay efficient, rides stay reliable, and customers keep renewing.

That means every decision connects revenue, customer experience, fleet capacity, and cost. These are the tools I built to make those decisions easier.

01 · WEEKLY FOUNDER OPERATING SYSTEM

One place to understand
the business every Monday.

RESULTOne weekly
decision view

The founders had information—but no single picture.

Revenue was in one sheet. Payments in another. Ride completion, leads, subscriptions, and operating issues were discussed elsewhere. Before a weekly review, someone had to chase updates and rebuild what happened.

A recurring operating view designed around founder decisions.

I connected the existing source trackers into one weekly review: money collected and due, rides completed and remaining, subscriber movement, lead movement, costs, and the issues that needed attention.

Less time collecting status. More time deciding what to do.

The Monday conversation started from one shared version of the business rather than multiple disconnected updates.

BEFORE5+ scattered sourcesSheets · messages · calls · updates
built one
weekly view
THE TOOLFounder Operating SystemRevenue · customers · leads · costs · issues
surfaced what
needed action
AFTEROne Monday reviewCollect · follow up · fix · prioritise

02 · UNIT ECONOMICS DECISION ENGINE

Revenue looked healthy.
The full economics did not.

RESULT0%+
lower burn

A plan could sell well and still destroy margin.

Looking at plan revenue alone ignored how often the customer travelled, the cost of operating those rides, acquisition cost, retention, and the ongoing effort required to serve the plan.

A plan-level model showing what was genuinely profitable.

I rebuilt the economics around the complete customer lifecycle: price, ride usage, cost per ride, CAC, retention, and cost-to-serve. I then used scenario models to test pricing and cost changes.

We found a plan was roughly 40% weaker than it appeared.

The finding gave the founders a concrete basis for repricing and removing cost leakage. The resulting decisions helped reduce burn by more than 50%.

HEADLINE VIEW“This plan earns revenue.”Only price was visible.
add every real cost
FULL-COST VIEW~40% weaker economicsRide usage + delivery + CAC + service
turn insight into action
Reprice planRemove leakageReview cost base→ 50%+ lower burn

03 · LEAD & CAPACITY EVALUATOR

1,500+ leads.
Only a limited number of seats.

RESULT0%+
more revenue

Demand was not the constraint. Supply was.

Pluto could only serve riders who fit available cabs and routes. Choosing manually from 1,500+ leads made it easy to miss someone who fit a free seat, could share an existing ride, or could replace a lower-value rider.

A tool that recommended the best use of each available seat.

It evaluated route fit, revenue potential, free capacity, shared-ride compatibility, and replacement value—then told the team the most useful next action for each lead.

Capacity became a revenue decision instead of a lead-list decision.

Compatible riders could be added to rides already running at close to zero marginal cost. Better allocation increased revenue by more than 30%.

INPUTNew leadHome · office · timings · price
1Fits a route?
2Seat available?
3Can share?
4Revenue lift?
RECOMMENDATION
ADDFill free seat
SHAREUse existing ride
REPLACEHigher value, same cost
HOLDNo viable fit yet

04 · FLEET ROUTING OPTIMIZER

Replace repeated dispatch calls
with workable route options.

RESULT0%+
lower cost

Every day’s fleet plan was a new puzzle.

Operators had to combine rider pickup points, office timings, live traffic, vehicle availability, pickup buffers, and empty travel—often through repeated calls and manual route comparisons.

A route-planning tool that generated feasible alternatives.

Using Google Routes API and configurable operating rules, it tested customer and vehicle combinations and returned two or three practical schedules for the operator to review.

The operator kept control, but reached the decision faster.

The tool made travel time, empty distance, and scheduling trade-offs visible before the fleet was assigned. Better options helped reduce cost by more than 25%.

INPUTSRider pickupsOffice timingsAvailable cabsLive traffic
GOOGLE ROUTES + OPERATING RULES
Test combinations · add buffers · calculate empty distance
OUTPUT
OPTION ALower empty distance
OPTION BFaster pickup sequence
OPTION CBest overall cost
Operator compares → chooses schedule

I carried the problem from the customer conversation to the team that could fix it.

This was not side work. It was how the systems stayed connected to what customers and founders actually needed.

01Talk to customersDaily conversations, friction, requirements
02Find the patternWhat is recurring? What blocks conversion or trust?
03PrioritiseP0/P1 ranking based on impact and urgency
04Write the briefOne or two pages with logic and edge cases
05Work with product & techClarify complexity, support implementation
Customer response closes the loop ↺
CROSS-FUNCTIONAL OWNERSHIP

Seven P0 product-flow improvements moved from customer friction to a technical fix.

I documented gaps across commute-day rules, paid trial logic, timing selection, fare clarity, and pack structure; ranked them; wrote clear briefs; and stayed involved while product and tech worked through the edge cases.

MY ROLECustomer voice+Business priority+Implementation context
FUNNEL & RETENTION SYSTEM

See exactly where the customer journey breaks—and investigate why.

I tracked movement from incoming lead to trial, payment, conversion, and repeat usage. If trial-to-paid weakened, or a cohort stopped repeating, the team could locate the stage and connect it back to the customer issue.

LEADTRIALPAIDREPEATDrop-off becomes visible here ↑
SEGMENTED CUSTOMER COMMUNICATION

Stop sending every rider the same message.

I grouped riders by route, lifecycle stage, payment status, and conversion risk. The system then supported the right communication: a commute update, payment reminder, trial follow-up, or conversion nudge.

ROUTELIFECYCLEPAYMENTRISK
RIGHT RIDER
RIGHT MESSAGE
RIGHT TIME
FOUNDER DECISION SUPPORT

Turn raw operations and research into something useful in the room.

I built investor decks, one-page briefs, performance summaries, market and competitor research, financial snapshots, and requirements notes—often on short notice before founder or investor conversations.

RAW DATAANALYSISDECISION BRIEFFOUNDER ACTION

A generalist who can move from customer detail to founder decision—and ship the system in between.

If a problem is important, cross-functional, and still being solved by memory or manual effort, that is usually where I am most useful.