Experiment Roadmap

Strata Self-Management App

You're not building a startup. You're running a sequence of experiments, each designed to test a specific hypothesis. Each experiment has a pass/fail gate. You only proceed to the next experiment if the current one passes.

Build-plan mindset
Phases defined by features to ship
Success = code is deployed
Sequence is fixed regardless of outcomes
Failure isn't defined — you just keep building
Experiment mindset
Phases defined by questions to answer
Success = hypothesis is validated or invalidated
Each gate decides whether to proceed, pivot, or stop
Failure is a legitimate, valuable outcome
20-Week Timeline · Decision Gates Between Each Experiment
Wk 1–3
Wk 3–8
Wk 8–10
Wk 10–16
Wk 16–20
EXP 0
EXP 1
EXP 2
EXP 3
EXP 4
Experiment 0 Weeks 1–3 ›
"I can ship a working multi-tenant web app in three weeks with my chosen stack."
This tests you, not the market. Can you, as a solo developer with Claude Code, actually deliver at this pace? If this takes six weeks, the entire roadmap is wrong and needs re-scoping.
What you build
  • Framework, database, ORM, deployment pipeline
  • Auth via managed service (Clerk, Supabase Auth, Auth.js)
  • Multi-tenant data model: buildings, users, issues, activity entries, contacts, issue links
  • A single screen: list of issues for one building
  • Deployed and accessible at a real URL
What you learn
  • Your actual velocity with this stack + Claude Code
  • Whether the data model feels right when you try to enter your real building's issues
  • Deployment friction — is the infra simple enough to not slow you down?
Pass → proceed
App is deployed. You can create issues and see them in a list. It took ≤ 3 weeks. Move to Experiment 1.
Fail → adjust
Took more than 3 weeks. Reassess: is the stack too complex? Are you over-engineering? Simplify and re-attempt before continuing. Do not proceed to Exp 1 with broken velocity.
Experiment 1 Weeks 3–8 ›
"A shared issue tracker with an activity log replaces my current workflow as committee chair."
The product hypothesis. Is the core concept — issues with chronological activity feeds, attached documents, tagged contacts — actually better than what you do now (email threads, spreadsheets, memory)?
What you build
  • Issue detail view with full activity feed
  • Activity entries: free text, status changes, file attachments, contact tags
  • Issue statuses: open, waiting on us, waiting on external, resolved, closed
  • Issue linking (many-to-many with optional labels)
  • Inline financial metadata on quotes/invoices (amount, supplier, status)
  • Contacts created on-the-fly when tagging activity entries
  • File storage via S3-compatible service
How you test it
  • Enter every open issue in your building — fire order, maintenance items, everything
  • Use it as your primary tracking tool for 2+ weeks. Stop using your spreadsheet/email.
  • Log every phone call, email, and meeting as an activity entry
  • Attach real documents — quotes, variations, EGM minutes
  • At the end of 2 weeks, ask: can I brief the committee from this tool alone?
Pass → proceed
You stopped using your old system. You can prepare for a committee meeting entirely from the app. You find yourself checking it instead of searching email. Move to Experiment 2.
Fail → pivot or stop
You keep reverting to email/spreadsheets because the app is missing something critical or adds friction. Identify what's missing. If it's a fixable feature gap, fix it and re-test. If the core concept doesn't feel right — if logging activity is busywork that doesn't pay off — reconsider the product thesis before showing it to anyone else.
Experiment 2 Weeks 8–10 ›
"Another committee chair will use this and pay for it without me standing over them."
The market hypothesis. Your own usage proves the concept works for you. This tests whether someone else — with different issues, a different building, a different tolerance for new tools — will adopt it and value it enough to pay.
What you build
  • Multi-user access: chair invites committee members by email
  • Role-based permissions: chair (full control), committee (comment, upload)
  • Email notifications on issue updates and comments
  • Stripe integration — one subscription tier, per building, per month
How you test it
  • Find 2–3 committee chairs from strata communities (Flat Chat, Facebook groups, personal network)
  • Set them up manually — create building, import their issues, walk them through it on a call
  • Charge them. Even $10/month. Price is not the test — willingness to pay is.
  • Check in weekly. Watch for: do they log in unprompted? Do they add entries without being asked?
  • Track the drop-off: how many sessions before they stop? What feature did they need that didn't exist?
Pass → proceed
At least 1 of 3 test buildings is actively using the app after 2 weeks, has entered their own issues, and paid (or is willing to). They say something like "where has this been?" or "I showed it to my committee." Move to Experiment 3.
Fail → diagnose
Nobody sticks after the onboarding call. Diagnose why: is the UX too rough? Is the concept wrong for them? Are they the wrong audience (maybe it's not chairs, it's strata managers)? Did they want something different (maintenance reporting, not issue tracking)? This is the most valuable failure — it tells you whether to iterate or pivot.
Experiment 3 Weeks 10–16 ›
"The features my early users ask for are things I can build, not a fundamentally different product."
This tests product-market convergence. Your early users will tell you what's missing. If their requests are enhancements to the issue tracker, you're on the right track. If they want an entirely different product, your thesis needs revisiting.
What you do
  • Weekly conversations with paying users — what frustrated you? What did you wish existed?
  • Build the most-requested features. Ship weekly.
  • Start the blog — you now have screenshots, a story, and credibility
  • First post: "Here's the tool I built to track our building's fire order"
  • Cross-post to strata communities. Measure: does anyone sign up from the blog?
What you learn
  • Whether feature requests converge (everyone wants the same thing) or diverge (everyone wants something different)
  • Whether committee members (not just the chair) use it — does it spread within a building?
  • Whether blog traffic converts to signups — is content a viable acquisition channel?
  • What the real churn pattern is — do buildings stay after month 1?
Pass → proceed
Feature requests are additive (more of the same), not divergent (something completely different). At least 2 buildings are still active. At least 1 new lead came from organic discovery (blog, community, word of mouth). Move to Experiment 4.
Fail → pivot
Users want a fundamentally different product. Or they stopped using it after month 1. Or nobody new discovered it. Each of these is a different kind of failure requiring a different response — but none of them mean "keep building the same thing."
Experiment 4 Weeks 16–20 ›
"Buildings can onboard without my involvement and the unit economics work."
The scalability hypothesis. Until now, you've been in every onboarding. This tests whether the product is self-explanatory enough that a stranger can sign up, understand it, and start getting value — and whether the price covers your costs.
What you build
  • Self-service signup: landing page → create account → create building → start tracking
  • Guided first-run experience: create your first issue, invite a committee member
  • Stripe Checkout in the signup flow
  • Automated database backups, error tracking, uptime monitoring
  • Minimal docs: help pages covering the basics, terms of service, privacy policy
How you test it
  • Post the landing page to strata communities. Don't offer to help — just link it.
  • Track the funnel: landing page → signup → created first issue → still active at day 7
  • Measure: what % of signups become active? Where do they drop off?
  • Calculate unit economics: revenue per building vs. infrastructure cost per building
Pass → you have a business
Strangers sign up without your help. Some percentage become active and pay. Infrastructure cost per building is a small fraction of the subscription price. You now have a product, a revenue stream, and a distribution channel. Everything after this is growth.
Fail → diagnose the funnel
Signups don't convert to active users. Either the landing page doesn't explain the value (marketing problem), the onboarding is confusing (UX problem), or the product doesn't deliver enough value for self-service users (product problem). Each is fixable but distinct.
When to Stop

The experiment mindset requires you to define what failure looks like in advance, not after the fact. These are signals that the project, in its current form, isn't working:

Stopping doesn't mean the idea is dead. It means this approach isn't working and the time is better spent finding a different angle — a different entry point, a different audience, or a different product shape entirely.

Operating Principles
Hypotheses before features
Every piece of code you write should be in service of answering a question. If you can't name the hypothesis, you're building on assumption.
Gates are real
If an experiment fails, you don't proceed to the next one. You diagnose, adjust, and re-run — or you stop. Ignoring a failed gate is the build-plan mindset sneaking back in.
Smallest testable version
Each experiment should test its hypothesis with the minimum possible code. If you're building more than you need to answer the question, you're hedging instead of testing.
Evidence over intuition
Your intuition says strata owners need this tool. Maybe. The experiments will tell you whether that's true, who exactly needs it, and what "this tool" actually is.