Many developers are not sure where to start a project - use this "pyramid framework" to start properly every time.

Myths & Mistakes

First, unlearn these myths and avoid these mistakes:

• Do not: Start with login, database, or Docker. These are plumbing. They don’t prove your product makes sense.
• Do not: Pick the framework first. Architecture decisions should follow validated requirements, not familiarity or hype.
• Do not: Build a full MVP before proving value. Start with a quick Proof of Concept (PoC) that shows the core outcome.
• Do not: Communicate in code/tech to business stakeholders. They live at the top of the pyramid (value, revenue, growth).
• Do not: Let your comfort zone choose the tech. Requirements (e.g., whitelabel, multi-tenancy) should decide the stack.
• Do not: Forget to think in levels. Seniors move fluidly from business outcomes to architecture to code and back.

Now, where to start a project?

Facts about Starting Projects

Lets use one example of building a "community for divers", where they can talk, maybe book som excursions and purchase some equipment.

Here are 3 important realities to keep in mind:

• Fact #1: Value sits at the top of the pyramid; code sits at the base. Budgets and buy-in happen at the top. If you can’t articulate the outcome and how it makes money, your tech choices won’t matter.
• Fact #2: Proof beats polish. A thin PoC that demonstrates the primary outcome de-risks the project far more than a perfect login screen. Build the RIGHT thing to 50%, not the wrong thing to 90%.
• Fact #3: Requirements dictate architecture. For example, a sudden need for a whitelabel, multi-tenant portal may push you toward tenant-per-database or tenant-per-table architecture. Choose Postgres/MySQL/Mongo AFTER you define the tenancy model with investors and owners - not before.

Now we know the stakes, how can you get started?

Actionable Tips To Start Any New Software Project The Right Way

Here's how I would get started:

• Step 1: Define the outcome and the value (thinking like an investor)
  • What problem are we solving FIRST, for whom, and how does it create value?
  • Example: A scuba diving portal where people find excursions and buy gear. Potential whitelabel model: each club gets its own storefront/landing; clubs pay monthly, and you take a % of sales.
  • Capture your value hypothesis in one short sentence. That’s the north star you will follow for now.
    ​
• Step 2: Build a PoC (top-down in pyramid, one thin vertical)

• Show the core outcome, not the plumbing. For the diving portal: display excursions and gear, and let users take the next step (e.g., “Request to book” or “Proceed to checkout”). No login. No full DB. Just enough to demonstrate flow and value.
• Put it in front of real people (investor, a few target users, friends and family). Gather feedback. Validate that the core outcome resonates. Decide key business requirements (portal vs. mobile app, whitelabel needs, monetization).
  ​
• Step 3: Translate validated requirements into architecture and code
  • Design for the business you just validated. If you need whitelabel/multi-tenancy:
    • Option A: Single database with tenant_id in all tables (faster start, risk of cross-tenant data leakage if you slip).
    • Option B: Database-per-tenant (more isolation, more ops overhead).
  • Choose the database engine (Postgres/MySQL/Mongo) to fit the tenancy model and data patterns. Not what you know or like, or prefer. You are not important here.
• Consider communication framework, like C4 model which this pyramid is "inspired by":

• Context: Why the system exists (customers browse excursions, make reservations, buy gear).
• Container: Big building blocks (e.g., Stripe for payments; Custom app for gear catalog; a lightweight booking service; Wordpress for content).
• Component: What you’ll build inside each container, like in gear catalog (browse, checkout, sell equipment).
• Code: Do not draw this manually, code diagrams will be generated from the code automatically (read more on C4 model website)

Then you would just work in loops: proof -> build -> test. Keep trimming scope to the smallest slice that delivers value and learning. And from there you expand, and from there you choose framework/database/login provider/programming language/whatever. That way you always know that what you are building is correct. And if you have new requirements or constraints - you just change one of the components, or adapt some other way.

That's it! This is how you start a new project!

Start from value, validate with a thin PoC, then let requirements choose your architecture and tech. And then you go into circles, and find new value, new tech, change it all if needed (because you now have new info), and you just keep building from there.

If this feels hard, that’s normal. I host free community workshops and volunteer sessions to help devs level up. Book a completely free session here, and we’ll find a way to help.

You can also watch the longer explainer:

​