How to Build a Business Model

Once something you built actually works for a few people, the question changes. It is no longer "is this useful?" but "can this sustain itself?" That is a question about your business model.

A business model is often presented as a canvas to fill in. Filling in boxes is not the hard part. The hard part is that the boxes are connected: change your customer and your pricing changes; change your pricing and your delivery cost has to change; change your delivery method and your reachable market changes. A business model is a system, and it either closes or it does not.

Separate the user from the customer

The first question is deceptively simple: who pays?

In student-facing products, the user is frequently not the payer. A study tool might be used by a student, paid for by a parent, and approved by a school. Each of those three has different criteria, and a product that delights the user while failing the payer's criteria will not sell.

Write down three roles explicitly:

• The user — whose hands are on the product.
• The payer — whose money leaves the account.
• The decider — who has authority to say yes.

When these are three different people, your model has to satisfy three different value propositions. That is not impossible, but it is much slower to sell, and it is a common reason campus products stall despite being liked.

Choose a revenue model that matches the behaviour

Revenue models are not interchangeable. Pick the one that matches how the value actually arrives.

One-time purchase. Suits a product whose value is delivered once — a course, a report, an assessment. Simple, but growth requires constant new customers.

Subscription. Suits value that recurs: ongoing access, continuing support, regularly updated data. Only works when the user experiences value at least as often as they are billed. Monthly billing for something used twice a year produces cancellations, not revenue.

Usage-based. Suits value that scales with volume — per applicant screened, per document processed. Aligns cost with value but makes revenue unpredictable early.

Marketplace commission. Suits two-sided models where you enable a transaction. Powerful and hard: you must solve supply and demand simultaneously, and you only earn when a transaction completes.

Institutional / B2B2C. A college, company or organisation pays; individuals use it. Larger contracts, far longer sales cycles, and usually a procurement process that a student team must plan for rather than discover mid-way.

Advertising or sponsorship. Requires meaningful, consistent audience volume before it pays anything. Rarely a viable first model for a young product.

A common student mistake is choosing advertising because it feels frictionless — nobody has to pay. In practice it postpones the hardest question, which is whether anyone values the product enough to give up something for it.

Price from value, then sanity-check against alternatives

Price is not calculated from your costs. It is anchored to the value the customer receives and the alternatives available to them.

Three inputs:

1. The value delivered. What does the customer gain or avoid losing? Hours saved, marks improved, a hire made, a fine avoided.
2. The next best alternative. What do they use now, and what does that cost in money and effort — including doing nothing?
3. Your cost to serve. The floor beneath which you lose money on every sale.

Then set a price and test it in a real conversation. Not "would you pay X?" but an actual offer with an actual payment request. Pricing conversations are uncomfortable, and avoiding them is the single most common gap in student business models.

Practical notes: it is easier to lower a price than to raise one; a small number of paying customers teaches you more than a large number of free ones; and a price so low that it signals "hobby project" can actively reduce demand in institutional sales.

Understand what one customer costs and returns

Two numbers determine whether a model closes.

Cost to acquire a customer. Everything spent to get one paying customer: outreach time, campus events, advertising, demos, the free trial you delivered by hand. As a student team, your time is a real cost even though no money moves — count the hours.

Value from a customer over their lifetime. Revenue per period × how many periods they stay, minus what it costs you to serve them each period.

If it costs more to win a customer than you earn from them, the model does not work, and growth makes the problem larger rather than smaller. That is the arithmetic behind many well-funded failures.

Also track gross margin — what is left from each rupee of revenue after the direct cost of serving that customer. A software product with an automated flow may keep most of it; a service delivered by human effort may keep very little, and that difference determines what kind of company you can build.

Test the model with the smallest real transaction

You do not need a full pricing page to test a model. You need one real transaction.

• Offer the outcome to five people at a defined price.
• Ask for payment before delivery, or a deposit.
• Deliver manually.
• Record how long the sale took, how many said no, and why.

A single completed payment answers questions that months of speculation cannot: whether the payer and decider are who you assumed, whether the price is inside their range, and how long the decision takes.

If nobody pays, resist the urge to conclude "we need more features". Ask instead: wrong person, wrong price, wrong moment, or wrong outcome?

Where student business models usually break

Free forever with a vague plan to monetise later. Monetisation is not a phase; it is a hypothesis that needs testing like every other.

Institutional customers assumed to be easy. Selling to colleges and companies involves procurement, budget cycles and multiple approvals. It is doable, but it needs a plan and patience.

Service costs treated as zero. If each customer needs two hours of your attention, you have built a job, not a scalable product — which is fine if you intend it, and fatal if you did not notice.

Pricing chosen by imitation. Copying a competitor's price without their cost structure or distribution usually produces a loss-making version of their business.

Ignoring payment mechanics. Who invoices, who approves, what documentation is required, when money actually arrives. Cash timing has ended more small companies than weak demand.

Write the model as connected claims

A good way to keep the system visible is to write your model as a short chain, each link testable:

We serve [specific customer]. They currently [alternative], which costs them [amount/effort]. We deliver [outcome] for [price], billed [frequency]. We reach them through [channel] at roughly [cost per customer]. Each customer costs us [amount] to serve, leaving [margin]. They stay for about [duration].

Every bracket in that paragraph is a number you can be wrong about. Fill them with your best current estimate, mark which ones are guesses, and treat the riskiest guess as your next experiment.

From model to narrative

When the model closes — even at small scale — you have something worth explaining to others: partners, mentors, institutions, competitions, and eventually investors. Explaining it well is its own skill, and it depends entirely on having the model straight first.

A clear model makes a clear story. Without one, no amount of design or delivery rescues a pitch, because the first serious question anyone asks is the one this work answers: who pays you, and does the arithmetic work?