u/Equivalent_Remote_88

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?

reddit.com
u/Equivalent_Remote_88 — 7 days ago

The part nobody warned me about: 8 months in, the build is 40% of the work — structure is the other 60%

Posting here because I think this audience has hit the same wall and I want to hear how you handled it.

I've been building an AI-empowered platform solo for the last 8 months. When I started I assumed the technical work would dominate — model integration, prompt design, RAG pipelines, agent orchestration, the usual. I was wrong by a wide margin.

The build was maybe 40% of the actual work to ship. The other 60% turned out to be structuring decisions that nothing in the AI-building conversation prepared me for. Six concrete ones I had to make:

1. Where to incorporate. I'm based in Georgia (the country, not the state). My users are global, with heavy EU/UK skew. Picking the entity jurisdiction isn't a tax question — it's a "which regulators will eventually care about what I'm doing, and will my payment processor work with this entity" question. I ended up Georgian LTD with possible UK or Estonian holding to add later. Took weeks of research and the answer is still partial.

2. Payment rails for AI products serving global users. Credit-card processing at 3–5% eats real margin on small transactions. Stablecoin settlement (USDC on Polygon for me) avoids that and the correspondent-banking friction for cross-border, but pulls in KYC, AML, and money-transmitter licensing questions in three or four jurisdictions at once. Most lawyers I talked to wouldn't give a clean answer.

3. KYC placement — at signup vs at money-movement. Friction at signup kills conversion. Friction at disbursement is heavier engineering. I deferred KYC to just before money moves, which is the right call for funnel but pushes complexity downstream.

4. Team without dilution. The standard advice is "find co-founders." For a project with a specific philosophical or aesthetic stance, co-founders can be coherence loss as much as capacity gain. I've stayed solo-technical with an analyst layer built from external recommendations. Slower, but the standard stays intact.

5. Marketing when your brand register is "restraint." Most growth playbooks tell you to be loud, scarce-pitched, urgent. If your positioning is the opposite — declarative not persuasive, friction as filtration — almost none of the standard playbook applies. I'm still figuring out what works. Niche communities and slow word-of-mouth seem to beat broad reach, but the data is thin.

6. The chicken-and-egg of network-effect platforms. How do you get the first 10 users when the value comes from there being more than 10? No clean answer here either. Working on it.

What I want to hear from this sub:

  • Which of these six did you hit hardest, and what did you actually do?
  • What did I miss? What structuring decision did you not see coming?
  • Anyone else solo-technical and refusing to add co-founders for coherence reasons — how's that going?

For context, I'm building Nexum (https://nexum.fund) — a community-pooled funding platform for AI builders. Most of these lessons came from making decisions for that project, but the patterns feel general. Happy to talk specifics on any of the six.

u/Equivalent_Remote_88 — 8 days ago