They don’t have bugs.

They don’t have awkward pages, missing features, confusing decisions, or parts you wish you had done differently. In your head, everything works exactly as intended.

Then you try to build it.

Suddenly, the clean idea becomes a collection of decisions.

What does it actually do?

Who is it for?

What belongs in the first version?

What can wait?

What happens when someone uses it differently than you expected?

And the question that can quietly keep a project unfinished for months:

What does this eventually need to become?

I’ve started to think that’s usually the wrong question to ask at the beginning.

I’m much more interested in a smaller one.

What can I make real today

The imaginary version is always bigger

When I start thinking about a new project, my brain rarely stops at version one.

I can see the expanded product before the basic one exists.

More features.

More pages.

Better systems.

Different ways it could make money.

Things I could add six months from now.

Maybe an entirely different direction it could eventually take.

There’s nothing wrong with thinking ahead. Some amount of planning prevents obvious mistakes.

But there is a point where thinking about the future stops helping the present.

You start building infrastructure for users you don’t have.

Creating systems for problems you haven’t experienced.

Adding features because they make sense theoretically.

Designing around a scale the project hasn’t earned yet.

The project gets bigger.

The launch gets further away.

And the original idea remains exactly what it was.

An idea.

Scope is a business decision

It’s easy to treat scope as a development problem.

I think it’s just as much a business problem.

Every additional feature costs something.

Maybe not money directly, especially if you’re making it yourself, but it costs time, attention, complexity, maintenance, and another decision that has to be made before the thing can leave your computer.

That’s still a cost.

So I’ve started asking a different question when I think something belongs in the first version:

Does this need to exist for the idea to work?

Not:

Would this be useful?

Would this make it better?

Could someone eventually want this?

Those questions produce very different answers.

There are countless things that could make a product better.

Far fewer things are necessary to make it useful.

Finding that line is one of the most valuable parts of building something.

Make the smallest version that proves something

“Start small” can sound like advice to lower your ambitions.

I don’t see it that way.

The ambition can stay large.

The first test should be small.

If I think something can become a useful business, I don’t need to build the entire business to test the assumption underneath it.

I need enough of the product to answer something important.

Will anyone use this?

Does it solve the problem the way I thought it would?

Can someone understand it without me standing beside them?

Will anyone pay for it?

Will they come back?

What do they ask for after using it?

Those answers are much more valuable than another month of speculation.

The first version isn’t supposed to prove that your entire vision is correct.

It’s supposed to give you better information.

Framebrix is teaching me this in real time

I’ve been thinking about this a lot while working on Framebrix.

The larger idea is easy to imagine.

Once you start thinking about templates, components, systems, resources, and everything that could sit around them, the possibilities expand quickly.

That’s exciting.

It’s also exactly how a relatively simple idea can turn into something that takes forever to release.

So instead of trying to make Framebrix immediately represent everything I think it could eventually become, I’m trying to focus on what it needs to be useful now.

A strong starting point.

Something thoughtfully designed.

Something another person can actually use.

Something real enough to learn from.

There will always be more I could add.

But I don’t need to predict every version of Framebrix before the first one has had a chance to exist.

I’d rather let the real thing teach me what the next thing should be.

Real use changes the roadmap

Planning has one major weakness.

Nobody has used the thing yet.

Before release, your roadmap is mostly a collection of educated guesses.

Some will be right.

Others will feel embarrassingly obvious in hindsight.

You might spend days building something nobody mentions and discover that the feature you considered unimportant is the one people keep asking about.

You might learn that your explanation is confusing.

You might discover that people don’t use the product the way you imagined.

Or the project might attract a completely different kind of customer than the one you originally had in mind.

You can’t plan your way into that information.

You have to put something in front of people.

That’s when the project stops being a theory.

Version one should create version two

This is probably the biggest shift in how I think about early products.

Version one doesn’t need to contain the future.

It needs to create enough information to make version two smarter.

That changes what “good enough” means.

Good enough doesn’t mean careless.

It doesn’t mean ugly.

It doesn’t mean broken.

And it definitely doesn’t mean releasing something you don’t believe in.

It means the product accomplishes what you said it would accomplish, even if the scope is intentionally narrow.

That’s an important distinction.

You can care deeply about quality while still limiting what you’re trying to build.

In fact, smaller scope can make quality easier.

Instead of spreading your attention across twenty features, you can make five work extremely well.

Instead of designing fifteen pages, you can make the three that matter feel considered.

Instead of trying to serve everyone who might someday use the product, you can make something genuinely useful for the first group.

Small doesn’t have to feel unfinished.

It can feel focused.

Architecture can become another form of procrastination

There’s a particular kind of procrastination that feels extremely responsible.

Planning systems.

Choosing technology.

Researching platforms.

Thinking about scalability.

Rebuilding the structure before the existing structure has actually failed.

It feels productive because you’re making serious decisions.

Sometimes those decisions are necessary.

Sometimes you’re designing the headquarters for a company that doesn’t have a customer yet.

I’ve caught myself doing versions of this.

The temptation is understandable.

It’s satisfying to build something clean enough that you imagine never needing to rebuild it.

But that’s rarely how real projects work.

Requirements change.

Tools change.

Customers change.

Your own understanding changes.

You change.

Trying to create an architecture that perfectly anticipates all of that can consume more time than simply building something reasonable and adapting when reality demands it.

Future flexibility matters.

Future perfection doesn’t exist.

Constraints can make the product better

A limited first version forces clarity.

If you only have enough time to build three things, which three actually matter?

If the homepage can communicate one idea, what is it?

If the product solves one problem exceptionally well, which problem should that be?

Constraints remove the luxury of hiding behind features.

You have to understand the core of the thing.

That can make a smaller product more compelling than a larger one.

The customer doesn’t necessarily care how many things you built.

They care whether the thing they came for works.

That’s a useful standard.

You can build the rest later

The internet has made iteration incredibly cheap.

A website isn’t printed in stone.

Software isn’t finished when version 1.0 appears.

A digital product can change tomorrow.

A business can discover a better customer.

A brand can sharpen its positioning.

A feature can be removed.

A completely new one can appear.

That should give us permission to stop treating every early decision like a permanent commitment.

You don’t have to solve the next five years.

You have to make a reasonable decision with the information you have now.

Then earn better information.

Build.

Release.

Observe.

Adjust.

The loop is more important than getting every individual decision right.

Make the idea real

There will always be a more complete version you could build.

A more sophisticated system.

A better design.

A longer feature list.

A more impressive launch.

That’s not the version competing for your attention.

The real competition is between the version that exists and the version that doesn’t.

So build what you can build today.

Make it useful.

Make it intentional.

Give it enough substance that someone can experience the idea instead of hearing you explain it.

Then put it somewhere reality can reach it.

Your first version doesn’t need to prove everything the idea could become.

It only needs to prove that the idea can become something.

You can build the rest from there.

If you wanted to build a website, you needed to understand code or know someone who did. Starting a publication meant dealing with hosting, design, distribution, and a dozen other things before anyone could read a word. Building software required enough technical knowledge just to get an idea onto a screen.

Most ideas died before they had a chance to become anything.

That has changed.

Today, I can have an idea in the morning and have some version of it online before the day is over.

I can ask AI to help me think through the concept. I can design the interface visually. I can start with a template instead of a blank canvas. I can connect tools that would have required custom development not that long ago.

The distance between idea and first version has collapsed.

That should mean we’re finishing more things than ever.

I’m not sure we are.

Because while technology has made starting dramatically easier, it hasn’t solved the much less technical problem of deciding when something is finished.

We solved the wrong bottleneck

For a long time, access was the problem.

You needed specialized knowledge, expensive software, equipment, distribution, or permission.

A lot of those barriers are disappearing.

AI can help you write code you don’t completely understand. Design tools can turn an empty canvas into a functioning website. Platforms can handle payments, email, hosting, analytics, and distribution without you building the infrastructure yourself.

These are incredible advantages.

But once the technical friction disappears, something interesting happens.

The remaining friction becomes much easier to see.

Judgment.

Focus.

Taste.

Commitment.

The willingness to choose one direction when ten others are available.

And eventually, the ability to say:

This is enough. Put it out.

No tool can completely make that decision for you.

More possibility creates more unfinished work

The old limitation was often, I can’t make this.

The new limitation is often, I could make this a hundred different ways.

That sounds like a better problem.

It is.

But it’s still a problem.

When changing direction costs almost nothing, direction becomes disposable.

You can rebuild the homepage.

Try another font.

Change platforms.

Generate twenty versions of the copy.

Add another feature.

Ask AI for ten alternative ideas.

Buy another template.

Reconsider the name.

Start over because the new version might be better.

And technically, you’re working the entire time.

That’s what makes it dangerous.

Procrastination doesn’t always look like doing nothing anymore.

Sometimes it looks like endless optimization.

There is always a better version

This is something I’m learning to be more aware of in my own work.

I like refinement.

I care about how things look, how they function, how the pieces fit together, and whether the final result feels intentional.

Those are useful instincts until they become an excuse to keep something private.

Because there is always another improvement available.

Always.

Give me another day and I can change something.

Give me another week and I can probably make it noticeably better.

Give me another month and I might rethink the entire thing.

That doesn’t necessarily mean I should.

At some point, improving the work and avoiding its release begin to look suspiciously similar.

The difficult part is recognizing when you’ve crossed that line.

Finishing requires constraints

Unlimited possibility sounds creative.

In practice, constraints often produce more finished work.

A deadline is a constraint.

A defined feature set is a constraint.

A publishing schedule is a constraint.

Choosing one platform is a constraint.

Deciding that version one only needs to solve one problem is a constraint.

Without those boundaries, a project can expand forever.

I’ve started thinking about projects less in terms of everything they could become and more in terms of what the current version needs to accomplish.

That distinction matters.

The first version of something doesn’t need to contain its entire future.

It just needs to justify the existence of a second version.

That makes finishing much easier to define.

Shipping changes the kind of information you have

Before something is released, most of your decisions are based on assumptions.

You think people will understand it.

You think a feature is important.

You think the design works.

You think the idea is interesting.

You think you’ve anticipated the problems.

Then someone actually uses it.

Suddenly, you’re working with reality.

The thing you spent hours perfecting might barely matter.

The small detail you almost ignored might be the thing everyone notices.

Someone might use what you made in a way you never considered.

Or nobody might care at all.

That information can be uncomfortable, but it’s useful.

You can’t get it from another week of polishing.

The unfinished version in your head can remain perfect indefinitely.

The finished version has to survive contact with other people.

That’s where the real work begins.

AI makes this even more important

AI has made the temptation to keep generating especially strong.

There is always another answer available.

Another variation.

Another concept.

Another image.

Another implementation.

Another way to say the same thing.

Generation used to be expensive.

Now it’s nearly infinite.

That changes the value of the skills around it.

When producing possibilities becomes cheap, choosing between them becomes more important.

Taste matters more.

Editing matters more.

Knowing what to remove matters more.

Knowing when to stop matters more.

The advantage isn’t simply being able to generate more.

Everyone can generate more.

The advantage is being able to look at endless possibility and decide:

This one.

Then do something with it.

Finished doesn’t mean permanent

I think part of the hesitation comes from treating publication like a permanent decision.

It rarely is.

Websites change.

Products evolve.

Writing gets sharper.

Ideas mature.

Brands change direction.

Software gets updated.

The version you release today doesn’t have to represent everything you’ll ever be capable of making.

It represents what you were capable of making now.

That’s enough.

The internet made iteration incredibly cheap.

We should probably take advantage of that instead of trying to make every first version feel final.

Publish it.

See what happens.

Learn something.

Change it.

That’s not lowering the standard.

It’s giving the work somewhere to go.

The new skill is finishing

We don’t have a shortage of tools.

We don’t have a shortage of information.

We definitely don’t have a shortage of ideas.

What we have is an environment where starting something new is constantly rewarded.

A new project feels exciting.

A blank canvas is full of possibility.

A new tool makes you imagine everything you could make with it.

Finishing is different.

Finishing means closing doors.

It means choosing one version over all the versions that could have existed.

It means allowing the work to become imperfectly real instead of potentially perfect.

Technology can’t remove that discomfort.

I’m not sure I’d want it to.

Because when almost anyone can start, the ability to finish becomes more valuable.

The tools will keep getting easier.

The distance between thinking of something and making something will keep shrinking.

We’ll be able to create more, faster, with fewer technical limitations than ever before.

But eventually, someone still has to make the call.

Stop generating.

Stop tweaking.

Stop preparing.

Finish something.

You’ve watched the walkthroughs. Saved the resources. Followed a few creators who seem to know what they’re doing. Maybe you’ve even completed a course or two.

You understand the interface. You know the terminology. You can follow along when someone else is building.

Then you open a blank project and suddenly realize you have no idea where to start.

I’ve been there more times than I can count.

It’s easy to mistake familiarity for ability. Watching someone build a website makes the process feel understandable. Following an AI tutorial makes the workflow seem obvious. Recreating a design step by step can make you feel like you’ve picked up the skill.

But following instructions and making decisions are two very different things.

A tutorial has already solved most of the difficult problems for you.

Someone else decided what to make. They chose the tools. They figured out the structure. They encountered the problems, found the solutions, cleaned everything up, and packaged the process into something you can follow from beginning to end.

That’s useful when you’re getting started.

Eventually, though, you have to remove the instructions.

Give yourself a problem

One of the biggest changes I’ve made in how I approach new skills is simple: I try to find something to make as quickly as possible.

Not a practice exercise.

Something with a purpose.

A website that needs to work. A template someone else could actually use. A small tool that solves an annoying problem. A redesign with constraints beyond making it look good.

The project doesn’t have to be groundbreaking. It doesn’t even have to become a business.

It just needs to force decisions.

That’s where a different kind of learning starts.

Instead of asking, “What should I learn about this tool?” you start asking much better questions.

How do I make this particular thing work?

Why is this breaking?

Is there a simpler way to structure this?

What happens on mobile?

How should someone move through this?

Can I reuse this instead of building it again?

Why did this look good in my head and terrible once I actually made it?

Those questions are difficult to manufacture inside a tutorial because they come from the project itself.

You start looking for information because you need it, not because someone put it in the next module.

The gaps become obvious

Projects are also good at exposing what you don’t know.

That can be uncomfortable.

You can spend hours consuming information and feel increasingly competent because everything makes sense while someone is explaining it. A blank canvas is less forgiving.

It immediately shows you where the gaps are.

That’s a good thing.

When I’m making something, I don’t need to understand every feature of every tool involved. I need enough knowledge to get from where I am to the next problem.

Then I solve that problem.

And then the next one appears.

Over time, those solutions start connecting.

Something you figured out while building one project becomes the obvious answer on another. A mistake that took an hour to diagnose the first time takes five minutes the next time. Eventually, you stop thinking about certain decisions altogether.

That’s when knowledge starts becoming skill.

Tutorials still have a place

None of this means tutorials are useless.

I use them all the time.

Documentation, YouTube videos, articles, AI, courses, forums, examples from other people’s work. There has never been a better time to find an answer when you’re stuck.

The difference is what comes first.

Instead of learning everything and hoping I’ll eventually find somewhere to use it, I’d rather start making something and learn what the project demands.

That changes the relationship with educational content.

A twenty-minute video becomes much more valuable when minute fourteen contains the exact solution to something that has been blocking you for the last hour.

You’re not collecting information anymore.

You’re applying it.

Build something slightly beyond you

There’s another advantage to project-driven learning: you control the difficulty.

If the project only requires things you already know how to do, you probably won’t learn much.

If it requires twenty things you don’t understand, you’ll probably abandon it.

The useful projects sit somewhere between the two.

You know enough to imagine how you might build them, but there are still parts that make you think, I have no idea how I’m going to do that.

Those are usually the parts worth doing.

Maybe you know how to design a landing page, but you’ve never built a reusable component system.

Maybe you know basic development, but you’ve never connected an API.

Maybe you use AI every day, but you’ve never tried turning one of your workflows into an actual tool.

Maybe you’ve built websites, but you’ve never packaged something so another person could use it without you explaining how.

Now you have a reason to learn.

And more importantly, you have a way to know whether you actually learned it.

The thing either works or it doesn’t.

Your projects become proof

There’s a practical benefit to this approach too.

When you finish a course, you have completed a course.

When you finish a project, you have something you can point to.

It can become a portfolio piece, a case study, a product, an experiment, a conversation starter, or simply evidence to yourself that you can take an idea from nothing to something tangible.

Even projects that go nowhere can leave something behind.

The abandoned website might teach you responsive design.

The tiny app nobody uses might teach you how authentication works.

The template that never sells might completely change how you think about reusable systems.

The project can fail and still do its job.

That’s a much better deal than waiting until you feel qualified enough to start.

Start before you know enough

I don’t think the goal is to stop learning.

It’s to stop treating learning and doing as separate stages.

You don’t have to finish every course before opening the software.

You don’t need to understand an entire programming language before making something with it.

You don’t need to master design before publishing your first site.

Learn enough to begin.

Then let the project show you what comes next.

Pick something small enough to finish and difficult enough to make you search for answers.

Give it a name.

Give it a purpose.

Put a deadline on it if you need one.

Then start making decisions without someone on the screen telling you which button to press next.

You’ll probably get stuck.

Good.

Now you have something worth learning.

In reality, though, a blank canvas isn’t always where the best work begins.

Sometimes the hardest part of building a website isn’t the design itself. It’s everything that comes before it. Figuring out the structure. Deciding what goes where. Building the same foundational sections again. Setting up responsive layouts. Creating a design system. Making sure everything feels consistent before you even get to the interesting part.

That’s where Framebrix comes in.

Framebrix is a collection of thoughtfully designed Framer resources built to give designers, creators, founders, and freelancers a stronger starting point.

Not a shortcut around good design.

A shortcut to it.

What Is Framebrix?

At its core, Framebrix is about reusable building blocks for Framer.

Templates. Sections. Components. Layouts. Systems.

The pieces you need to take an idea from “I should build this” to something that actually exists on the web.

Instead of rebuilding common patterns every time you start a new project, Framebrix gives you a foundation you can take apart, customize, combine, and make your own.

That last part matters.

I don’t want Framebrix to become another collection of templates where you swap a logo, change three colors, replace the text, and call it a day.

The goal is to give you enough structure to move faster without making every website look like it came from the same template.

Think of it more like a box of digital building blocks.

You decide what gets built.

Why I Built It

The more time I spent designing websites, the more I realized how much of the process gets repeated.

A new project might look completely different from the last one, but underneath it, I’m still solving many of the same problems.

Navigation.

Hero sections.

Pricing.

Features.

Calls to action.

Footers.

Responsive behavior.

Spacing.

Typography.

Content hierarchy.

There’s no reason every project needs to start from zero.

And as I’ve gotten deeper into Framer, I’ve become more interested in systems than individual pages.

How can something be designed once and reused intelligently?

How can I spend less time rebuilding the predictable parts and more time thinking about what actually makes a site interesting?

How can a good starting point make the final result better instead of just faster?

Framebrix grew out of those questions.

It’s essentially me taking the things I find useful in my own design process, refining them, and turning them into resources other people can build with.

It’s Not About Making Design Generic

There’s an obvious downside to templates.

You can usually tell when someone used one.

Same oversized headline.

Same floating cards.

Same gradient.

Same startup dashboard sitting inside a laptop mockup.

Same website with a different company name.

That isn’t what I want Framebrix to encourage.

A good template should give you structure without dictating the final result.

A good component should solve a problem without deciding your entire visual identity.

And a good system should make customization easier, not discourage it.

Framebrix is designed around that idea.

Use the whole thing.

Use one section.

Pull out a component.

Change everything.

Break it apart and rebuild it.

The resource is the starting point, not the finished product.

Who Framebrix Is For

Framebrix is for people who want to build better websites without making the process unnecessarily complicated.

Designers can use it to speed up repetitive parts of client work and spend more time on the details that actually make a project unique.

Freelancers can use it to create stronger workflows, especially when juggling multiple projects or working within tighter timelines.

Founders can use it to get an idea online without needing to become professional designers before they can launch something that looks credible.

Creators can use it to build polished homes for their work, products, newsletters, communities, and ideas.

And if you’re still learning Framer, Framebrix can also be something to take apart.

One of the best ways I’ve learned design and development tools is by opening something that already works and asking:

How did they build this?

Then changing it.

Breaking it.

Rebuilding it.

Making it mine.

I want Framebrix to be useful in that way too.

Built for Framer

There are a lot of website builders out there, but Framer has become the one I genuinely enjoy working in.

It hits an interesting middle ground.

It gives designers enough freedom to care about the details while making it possible to actually ship what they design.

That changes the relationship between designing and building.

You’re not creating something in one tool and hoping it survives the transition into another.

You’re building the actual thing.

Framebrix leans into that.

Everything is designed around the idea that modern websites should be easier to create, easier to customize, and easier to maintain without sacrificing personality.

More Than Templates

Templates will be part of Framebrix, but I don’t want the brand to stop there.

I see Framebrix as a growing library of resources around building for the modern web.

Some resources will help you start an entire website.

Others might solve one very specific problem.

Some will be complete systems.

Others might just be a small component that saves you 30 minutes the next time you need it.

That flexibility is intentional.

Not every project needs a massive design system.

Sometimes you just need a really good section.

Build Faster. Make It Yours.

There’s a strange idea in creative work that doing everything from scratch somehow makes the work more legitimate.

I don’t really believe that anymore.

We all build on something.

Fonts.

Frameworks.

Libraries.

Inspiration.

Design patterns.

Software.

Ideas we’ve picked up from other people.

The important part isn’t whether you started from absolute zero.

It’s what you do with the starting point.

That’s the philosophy behind Framebrix.

Give people better building blocks.

Make those blocks easy to work with.

Leave enough room for creativity.

And help more ideas make the jump from something sitting in your head to something people can actually visit, use, and experience.

That’s Framebrix.

And it’s coming soon.

I’m starting to believe that’s the wrong goal.

The better goal is to keep redeveloping.

That’s what this newsletter is about.

Not becoming an expert with all the answers. Not pretending to have life figured out. Just staying curious enough to keep learning, building, and improving.

I’m a designer, developer, business owner, veteran, and lifelong student. Every chapter of my life has required me to start over, learn new skills, and rethink what I thought I knew. Somewhere along the way, I realized that growth isn’t a destination. It’s a habit.

Here you’ll find ideas on design, software, AI, digital business, creativity, and personal growth. Sometimes we’ll break down tools. Sometimes we’ll explore mindset. Sometimes we’ll simply chase an interesting question together.

If there’s one theme you’ll notice, it’s this:

Everything can be redeveloped.

Your skills.

Your business.

Your habits.

Your thinking.

Even your definition of success.

I don’t write from the perspective of someone standing at the finish line. I write as someone who’s still walking the path, sharing what I’m learning as I go.

If that sounds like the kind of journey you want to be part of, you’re in the right place.

Let’s redevelop what’s possible.

Thanks for reading Redevelop!

Subscribe for free to receive new posts and support my work.