Kosh began from a simple observation: freelancers and clients already have ways to send money, share files, and discuss work. What they do not have is one shared place where scope, proof, review, payment, ownership, and the final record stay connected.
UPI can confirm that money moved. Drive can confirm that files were shared. WhatsApp can confirm that someone said yes. None of them creates one shared contract state both sides can trust.
Scope, revisions, approvals, and expectations are scattered across informal messages.
Files can be shared before payment is settled, creating review access without ownership clarity.
Payment moves quickly, but it does not explain what was approved, what changed, or what remains pending.
They document an agreement at one moment, but they do not stay alive as work moves through review, dispute, and release.
The work begins with informal clarity, but the actual scope lives across messages, screenshots, PDFs, and memory.
A client needs to see the work before paying, but sending files too early can quietly transfer leverage.
UPI confirms money moved. Drive confirms a file was sent. WhatsApp confirms someone said yes. None of them creates one shared contract record.
The research did not ask whether freelancers needed another payments product. It asked where trust breaks when agreement, proof, review, files, and payment all live in different tools.
Eleven informal conversations, six freelancers and five clients, focused on scope, review, payment anxiety, file handoff, and what happens when a project goes badly.
WhatsApp, UPI, Drive, invoices, contracts, and marketplaces were treated as one existing stack, then compared by what each tool carries and what each tool drops.
UPI scale, freelance work in India, MSME and formal recourse paths, and payment-partner constraints were reviewed to separate infrastructure problems from coordination problems.
A freelance engagement was mapped from first DM to final payment to identify where the agreement stops being readable by both sides.
When both sides described a project that went badly, the visible failure was usually money. The underlying failure was earlier: what was promised, what was submitted, and what counted as done.
The freelancer and the client described different symptoms, but the missing layer was the same: no shared record of what had been agreed, submitted, reviewed, or released.
The freelancer's problem was not only late payment. It was having no neutral place to point to scope, submission, approval, and ownership state.
The client's problem was not only trust in the freelancer. It was not knowing whether review, revision, acceptance, and final ownership had been clearly separated.
UPI moves money quickly, but the payment record does not carry scope, proof, approval, or ownership state.
Many independent projects begin through referrals, DMs, and WhatsApp, outside formal marketplace rails.
Formal dispute and recovery systems are easier to understand for registered businesses than for informal independent work.
The tools most freelancers and clients already use each move one thing and assume the rest is handled elsewhere. The gap is the right-most column: a connected contract state.
| Capability | UPI | Drive / transfer | Marketplace | Kosh direction | |
|---|---|---|---|---|---|
| Scope is structured and shared | |||||
| Proof of delivery is timestamped | |||||
| Review is separate from ownership | |||||
| Money is tied to the agreement | |||||
| Dispute has a structured path |
Not built in Partial / depends on discipline Built into contract state Regulated payment partner
The research became useful only when each pattern forced a product decision.
Money could move, but scope, proof, approval, and ownership were rarely held together.
Design the agreement, not a separate money surface.
The same person could be provider in one project and commissioner in another.
The contract assigns the role, not the account.
Clients need to review work before payment, but freelancers need to protect final handoff.
Separate review access from ownership transfer.
When trust breaks, informal tools turn conflict into screenshots, reminders, and social pressure.
Treat dispute as a first-class contract state.
The research shifted the product away from "hold the money until both sides are happy" toward a sharper idea: money only creates trust when it is connected to scope, proof, review, ownership, and record.
The agreement is the artifact. Payment is the consequence. Kosh starts with scope, milestones, proof, and ownership terms before money enters the workflow.
A Kosh contract is not a PDF folder. It is a shared state machine both parties read at the same time: draft, accepted, funded, submitted, reviewed, disputed, released, and recorded.
Submitted work can be reviewed before release, but final ownership transfers only when payment is released. The product separates seeing the work from owning the work.
When trust breaks, the contract should not disappear into support. Kosh treats dispute as a visible state with partner-custodied funds frozen, structured response, and a recorded outcome.
Kosh became clearer by rejecting three familiar product shapes and keeping only what helped the agreement stay alive.
The answer was not to replace the relationship, hold money as the whole product, or freeze the agreement inside a document.
It would add profiles, discovery, bidding, ratings, and platform mediation before the real trust break had happened.
Existing relationships stay direct. Kosh only adds the agreement layer around work that already exists.
Payment protection alone still leaves scope, proof, review, ownership, and release conditions scattered across tools.
Payment has meaning only when tied to contract state. Money follows the agreement instead of becoming the product.
A PDF can clarify terms at the start, but it becomes static once work begins and proof starts moving.
The agreement stays alive after signing. Scope, proof, review, ownership, payment, and record move together.
Kosh became the coordination layer between agreement, proof, review, ownership, payment, and record.
Kosh could not split users into permanent freelancer and client accounts. The same person might provide work in one contract and commission work in another, so the architecture makes the contract assign the role, not the account.
Kosh does not ask users to permanently choose freelancer or client. A user keeps one account, and their role changes inside each contract.
The contract is the shared object both sides can read. It carries scope, funding state, submissions, review, ownership, and record.
The milestone is the trust unit. Funding, proof, review, dispute, release, and ownership transfer happen around milestones, not around a vague project status.
Kosh handles real money between people who do not fully trust each other yet. The interface had to feel like a shared document, not a finance dashboard: warm paper surfaces, restrained product colour, and plain language wherever the system would rather explain its mechanism.
The section works like a compact design-system artifact, but every foundation, primitive, and component points back to the same product idea: both sides must understand what is agreed, what is live, what is recorded, and what happens next.
Includes: logo and wordmark, colour and type system, brand guidelines PDF.
Excludes: packaging and social templates. Adding these later needs a recorded amendment.
Every edit on the left updates the agreement on the right in real time. There is one record, and both parties are reading the same draft before anything is sent.
The editor is the working surface. The agreement is the warm record. The colour difference tells you which half can still change and which half is becoming the document.
Includes and excludes are written as the client would read them, not as scope flags. The exclusion line states the consequence in human terms.
Being written. Not yet sent.
Money with the payment partner. Work can begin.
Submitted. Preview only, not delivered.
Paid. Files now belong to the client.
Funds paused. A structured path opens.
Closed record. Read-only for both.
Kosh did not become coherent through one big idea alone. It became coherent through a series of smaller decisions, each one separating something other tools blur together: role and account, review and ownership, dispute and support, release and payment, mechanism and language.
Kosh does not split users into permanent freelancer and client accounts. The same person can provide work in one contract and commission work in another, so the role belongs to the contract itself.
Why it mattered This keeps the IA simpler, avoids false identity choices, and matches how independent work actually happens.
Akshat provides work here. In another contract, the same account can commission work.
Creator for this contract
Client for this contract
Clients need to review work before releasing money, but freelancers still need protection during that review. Kosh separates preview access from final ownership transfer.
Why it mattered That separation solves the usual file-sharing trap: work can be reviewed without quietly giving away the final handoff.
Preview access is open. Final files transfer only after release.
Watermarked proof is visible for approval. Ownership transfer is tied to release.
When trust breaks, Kosh does not push people into vague reminders, screenshots, and support tickets. Dispute becomes a first-class contract state with paused funds, clear status, and a recorded path forward.
Why it mattered Treating dispute as product state makes conflict legible instead of social.
Funds paused with payment partner while both sides respond on the record.
The most consequential moment in Kosh is when payment and ownership move together. That moment needed more weight than a generic button press.
Why it mattered Giving release its own ritual makes the consequence visible: this is the point where money moves, files transfer, and the record becomes final.
This records the approval, releases payment, and transfers the final files.
Kosh avoids mechanism-heavy wording when the user really needs situational clarity. The interface says things like "Rahul reviewing, release due 19 Jun" instead of forcing people to decode internal system language.
Why it mattered Language becomes part of the product behaviour. It keeps the agreement readable when money, timing, and anxiety are in play.
Rahul reviewing, release due 19 Jun
Preview is open. Final files transfer on release.
Payment partner confirms funded commitment.
Akshat signs in once. This contract assigns him as creator, while another contract can assign him as client.
Creator in this contract. Owns proof submissions and handoff.
Client in this contract. Reviews proof and releases payment.
The account stays personal. The contract carries the temporary relationship, permissions, and next action.
The client can inspect the proof, but final ownership transfers only when payment is released.
Watermarked proof is open for review. Final files stay pending.
Final files belong to Rahul only after release is confirmed.
Logo system preview, brand guidelines PDF preview, and handoff checklist are attached for approval.
Funds are paused with the payment partner while the issue is handled inside the shared record.
This records approval, releases payment through the payment partner, and transfers the final files to Rahul.
₹30,000
Milestone 2 payment moves after confirmation.
Final files become available with the release record attached.
The system explains what is happening without making users translate internal mechanism names.
Rahul reviewing, release due 19 Jun
Preview is open. Final files transfer on release.
Payment partner confirms funded commitment.
Both sides will keep the same release record.
Every state a real contract passes through, for both sides, grouped into the five flows it moves through.
