The 6 structural decisions solo founders hit between "I built something" and "I'm running a business" — what I learned across 8 months
Posting this as a resource because I had to figure each of these out the hard way and the information is scattered across legal blogs, founder DMs, and outdated forum threads. Hopefully useful to others hitting the same wall.
When you ship a real product, ~40% of the work is the build. The other ~60% is structural decisions nobody warns you about. Here are six concrete ones, with options and what I actually chose:
1. Where to incorporate
The question isn't tax-driven. It's: which regulators will eventually care, which payment processors will work with you, and which jurisdiction your users trust.
Real options for a solo founder serving global users:
- Delaware C-Corp ($300-600 + Stripe Atlas $500) — investor-friendly, US payment processors accept it, but creates US tax filing obligations from day one
- UK Ltd (~£12) — cheap, fast, reputable globally, works with most EU/UK processors, can be done online in 24 hours
- Estonian e-Residency + OÜ (~€300) — fully digital, EU-resident, good for SaaS, lower friction than UK for non-residents
- Local entity (your own country) — cheapest, but payment processors and investors may reject it depending on jurisdiction
- Singapore Pte Ltd ($300-1000) — strong for Asia-facing businesses, requires local director
I went with a local entity in my country with plans to add a UK or Estonian holding later for investor legibility. Cost: ~$100. Tradeoff: limited processor options, which led to decision #2.
2. Payment rails for global small transactions
Credit cards at 3-5% + fixed fees eat margin on small cross-border transactions. Real options:
- Stripe / Paddle / Lemon Squeezy — works for most US/UK/EU entities, won't onboard some jurisdictions, 3-5% all-in
- Wise Business — multicurrency receiving, decent for invoicing, doesn't handle subscriptions cleanly
- Mercury / Brex — US-only banking, not for non-US entities
- PayPal — high friction, expensive, but works everywhere
- Stablecoin settlement (USDC on Polygon/Base/Solana) — fractions of a cent per transaction, no jurisdiction onboarding, but pulls in compliance complexity
- Bank transfer / SEPA / ACH — cheap but high friction, terrible UX
I went with USDC on Polygon for the platform's funding flows after Stripe wouldn't onboard cleanly. Implemented HMAC signature verification on webhooks (non-negotiable — without it anyone can POST fake payment events). Used Fastify's raw-body parsing to verify signatures before processing.
3. KYC/AML — at signup vs at money movement
The decision: do you collect identity verification at registration (high friction, kills conversion) or at the point money actually moves (lower friction, heavier engineering downstream)?
- At signup — lower legal risk, much higher abandonment, simpler architecture
- At first transaction — middle ground, used by most fintechs
- At disbursement only — best UX, requires you to build a robust verification step into the disbursement flow and document why you defer
I deferred KYC to just before disbursement. Lower friction, but the disbursement service became more complex. Worth it for my model; would be wrong for a payments-on-day-one platform.
4. Team structure without equity dilution
Standard advice: find co-founders. For projects with a specific philosophical or aesthetic stance, co-founders can mean coherence loss as much as capacity gain.
Options I evaluated:
- Co-founders (10-30% equity each) — fastest capacity, biggest dilution and coherence risk
- Early employees with equity (0.5-2% each) — slower hiring, smaller dilution
- Contractors paid in cash — no equity, no coherence loss, no long-term commitment
- Advisor pool (0.1-0.5% each) — vouching, network, no daily capacity
- External recommendations + paid analysts — closest to "extended cohort," scales slowly
I stayed solo-technical with an analyst layer being built from external recommendations. Slower, but the brand register stays consistent.
5. Marketing when your brand register isn't "loud"
Most growth playbooks assume your positioning is mass-market, scarcity-pitched, urgent. If your positioning is the opposite — declarative not persuasive, friction as filtration, cohort quality as the product — almost none of the standard playbook applies.
What I've seen work for serious-tool products:
- Niche-targeted ads diffusing through small specific communities outward
- Editorial pitches to publications your audience already reads
- Showing up in discussions (like this one) with substance, not pitches
- Direct outreach to specific people who'd recognise themselves
- One-deep engagement in 2-3 Discord/forum communities over months, not posting to 30
What doesn't work:
- Cold LinkedIn DMs
- Mass Twitter threads
- Press release distribution (devalued by Google updates)
- Paid SEO services for early-stage products
6. The chicken-and-egg of network-effect products
If your product's value comes from having other users on it, getting the first 10 is hard.
Approaches I've seen work:
- Single-player utility first, network effects later (Notion's playbook)
- Seed one specific community by being physically present in it
- Pay the first 10 users for their participation (works for B2B, awkward for consumer)
- Build the second side first (marketplaces — find sellers before buyers, or buyers before sellers)
I'm still working on this one. Don't have a clean answer.
Context: I'm building Nexum (nexum.fund), a community-pooled funding platform for AI builders. Each of these decisions came from making them for that specific project. Happy to go deeper on any of them if useful.
What did I miss? What structural decision did you not see coming when you started shipping?