How to Know What to Build ​

Probably one of the hardest questions I’ve ever been asked is:

“What should I build?”

Not because I don’t have ideas.

I have way too many ideas.

For me, the real problem has always been: what do I build now from my long list of things I’d love to build “someday”?

If you’ve ever stared at a notes app full of project ideas and felt weirdly paralyzed…I've been there.

When someone asks “what should I build?”, I’ve learned they usually mean one of these:

• “What should I build to get better at $X?”
• “What should I build to get hired / promoted?”
• “What should I build to solve a real problem?”
• “What should I build that I’ll actually finish?”

Those are different questions, and they produce very different projects.

So before you pick the tech stack or open a new repo, pick the reason.

This is the simplest rule I know that actually works:

Build for the environment you’re in today… or the environment you’re aiming for next.

If you’re working in SharePoint / M365 ​

Don’t fight it. Lean into it.

Build things like:

• A list-driven internal tool (views, forms, validation)
• Custom pages that solve a real “this is annoying every day” problem
• A small add-in/extension that removes clicks for your team
• A “glue” layer: automate provisioning, permissions, content moves, reporting

You’ll learn valuable stuff because you’re building in a place where constraints are real and stakeholders are real.

If you want to move into cloud / infra / server management ​

Build automation and infrastructure.

• Scripts that take a repetitive manual process and turn it into a single command
• A “bootstrap” repo that builds a full dev environment from nothing
• IaC modules (Bicep/Terraform) you can reuse for every environment

You don’t need a perfect production platform to learn here. You need reps.

If you’re learning web dev ​

Build small, visible wins.

• A component library clone (tabs, modals, toasts, tables)
• A marketing site with good typography and performance
• A tiny app that reads/writes data and has a real UI state machine

HTML/CSS/JS is not “basic.” It’s the foundation. And foundations are where projects either stand or collapse.

As you grow, your “tool belt” grows.

At first, your tool belt might be:

• basic scripting
• a bit of frontend
• enough Git to be dangerous

Later, it might include:

• API design
• background jobs
• CI/CD
• observability
• IaC

The skill isn’t “knowing tools.”

The skill is seeing problems and being able to say:

• “I can solve that with what I already know.”
• “I can solve that if I learn one new thing.”
• “I should not attempt that yet (and that’s fine).”

That last one is underrated.

If you’re stuck between projects, run each idea through this (fast) filter:

1) Pull (will you care in two weeks?) ​

If you don’t actually want the outcome, you won’t finish.

2) Leverage (does it help future-you?) ​

Prefer projects that create reusable assets:

• a module
• a template
• a repeatable workflow
• a set of patterns you can reuse at work

3) Scope (can you ship a V1 in a weekend?) ​

If the smallest slice still takes months, you’ve designed a fantasy novel, not a project.

A good project idea becomes great when you can write a V1 like this:

• “A script that does the one annoying thing”
• “A page that shows the data clearly”
• “A deploy pipeline that runs on every push”

4) Proof (can you demonstrate value?) ​

This matters for resumes/portfolios:

• a before/after time savings
• a measurable improvement
• a clean demo
• a crisp README

If you want a simple scoring trick: give each category a score from 1–5 and build the project with the highest total.

No, it’s not scientific.

Yes, it works.

I’m going to say something that might sound “anti-AI” at first, but it isn’t:

Even if AI can do it for you, it’s irresponsible to let it when you don’t understand the fundamentals of what it’s writing.

AI can help you move faster, but it will also happily generate:

• brittle code
• unsafe patterns
• inconsistent architecture
• incorrect assumptions that look confident

The goal is not “never use AI.” The goal is:

• Use AI to accelerate work you can validate
• Use AI to learn faster, but don’t outsource comprehension

A practical rule I like:

• If you can’t explain the code to a teammate (or to yourself tomorrow), you don’t own it yet.

And if you don’t own it, you can’t maintain it.

If you want examples that usually produce real learning without turning into an endless side quest:

SharePoint / M365 track ​

• A “site audit” tool that inventories permissions, owners, and stale content
• A provisioning script that builds a new team/site/list structure from a config file
• A dashboard page that turns “where is this document?” into a 10-second answer

Cloud / automation track ​

• A repo that spins up an environment from scratch (network + app + monitoring)
• A “one command” deployment pipeline with a rollback story
• A secrets + config strategy you can explain clearly (and replicate)

Web dev track ​

• A small app with authentication and state management and good UX
• A component set that focuses on accessibility (keyboard nav, focus states)
• A performance pass: make the Lighthouse score boringly high

The best projects are the ones you can ship, then improve.

My best piece of advice is simple:

Stay hungry and stay curious about technology that enables you to provide whatever value you’re looking to provide.

Build the thing that helps “future you.”

Then ship it.

Then build the next thing.