We were getting ready to raise for Sane. That meant pitch decks, financials, and legal docs going out to investors. Google Drive gives you a link and nothing else. DocSend tracks views but cannot collect signatures. DocuSign collects signatures but tells you nothing about engagement. I needed all three in one place, so I built it.
The Dealbase dashboard. Four KPI cards, room overview, recent shared links, and a live activity feed.
Problem Definition
If you are a founder raising money, you send your pitch deck to dozens of investors. Then you wait. You have no idea if they opened it. You do not know if they spent ten minutes on your financials or skipped straight to the team slide. You cannot tell if they forwarded it to a partner or deleted the email.
That matters more than it sounds. It changes how you run a fundraise. Without engagement data, you follow up blindly. You waste time chasing investors who never opened the deck and miss the ones who read every page twice. The fundraising process is already inefficient. Flying blind makes it worse.
Competitive Landscape
DocSend does document tracking well. You get view counts, time spent, page-by-page analytics. But it cannot collect signatures. When you need an NDA signed before sharing a term sheet, you are back to DocuSign.
DocuSign handles signatures. But it has no concept of document engagement. You know someone signed, not whether they actually read what they signed. And the pricing is built for enterprises, not founders.
Google Drive is free, familiar, and useless for anything beyond storage. No analytics, no access control beyond "anyone with the link," no signatures, no audit trail.
The gap was obvious: nobody combined secure sharing, per-page analytics, and e-signatures in one product at a price that made sense for a startup. So that became the product.
The Build
People hear "built in a week" and assume it was hacked together. It was not. It was fast because the planning was thorough.
Product Rigour
The PRD does not say "users should be able to share documents." Every story has a concrete scenario, the kind you can test against, word for word. Here is one of the 46:
That level of detail is not extra work. It is the reason the build went fast. When I got to day 4 and needed to build the share modal, I did not have to think about what it should do. The PRD already told me. I just built what it said.
Feature Depth
The share modal. Recipient name, password protection, NDA gate, watermark toggle, download control, expiry date.
UX Decisions
A document sharing platform has two very different users: the person sharing (the founder) and the person viewing (the investor). The product has to work well for both, but they have completely different needs.
Edge Cases
Edge cases are where products fall apart. A polished happy path means nothing if the unhappy paths feel broken.
Security Architecture
A document sharing platform that leaks data between users is worse than useless. Row Level Security is enabled on all 15 tables. Every query scopes to the user's organisation. A user in one org cannot see, query, or even accidentally stumble into another org's data.
The service role is used only where it has to be. The signing API needs it because signers do not have accounts. The tracking API needs it because viewers do not have accounts. Webhook deliveries need it to push events externally. Everywhere else, the user's own auth token determines what they can see. This was a deliberate decision, written into the PRD under "Security Requirements" before a single table existed.
Technical Architecture
The system splits into two tracks: authenticated users (the founder) and unauthenticated users (the viewer/signer). Both hit the same Supabase backend, but through different permission levels.
System architecture. Four client types, six core API routes, Supabase with RLS on every table.
Per-document analytics. View count, time spent, scroll depth, page-level heatmap, and engagement score.
Information Architecture
The navigation groups around what you are doing, not what the feature is called. Dashboard is your morning check-in. All Rooms is where you manage content. Analytics is where you study engagement. Signatures is where you manage signing workflows. Settings is where you configure your workspace. Trash is where mistakes go to be undone.
The page count (33) sounds like a lot. But a user in the middle of a fundraise only touches five or six of them regularly: Dashboard, a specific Room, Share modal, Analytics for that document, and maybe Signatures. The rest, like Audit Log, Compare, Folder Analytics, and Settings, are there when they are needed and invisible when they are not.
Monetisation Design
Free gives you enough to test: one room, ten documents, thirty share links, basic view counts. That covers a solo founder sharing a single pitch deck.
Pro ($12/month) unlocks the intelligence: per-page analytics, NDA gates, watermarks, e-signatures, audit log, CSV export. This is the fundraising tier.
Business ($29/month) adds collaboration: up to 10 team members, webhooks, API keys, white-label branding on the viewer. This is the law firm / advisory tier.
The tiers map to user maturity. A founder raising a seed round does not need webhooks. A law firm managing client data rooms does not need a free plan. The lines are drawn where the use cases actually change, not where the feature count hits an arbitrary threshold.
Scope Discipline
The PRD has an "Open Items" section. These are features I evaluated, thought through, and chose to leave out. Not because they are bad ideas. Because they are wrong for week one.
Success Metrics
The first test was simple. I shared Sane's actual pitch deck through Dealbase instead of Google Drive. Watched the analytics come in live. Saw which slides investors spent time on. Followed up with the ones who engaged. That was the validation.
Longer term, the metrics that matter are: documents shared per user per month (are people using it?), average viewer engagement time (is the tracking useful?), signature completion rate (does the signing flow work?), and free-to-Pro conversion (is the product worth paying for?).
What Comes Next
Four things are planned: Stripe/Paystack for payments when there is demand. Geographic viewer data for investor location intelligence. Document comparison for A/B testing decks. Custom domains per organisation for white-label use cases. Each one has a priority, a rationale, and a rough scope already written. They will get built when the product needs them, not before.
What I Learned