Stop starting, start finishing

Pawel Kubiak

2025-10-20 8 min read

#Productivity
#Personal Story

November 2023. Angular 17 had just dropped, and I was buzzing with excitement. The new control flow syntax, SSR improvements, the new application builder – it felt like the perfect time to finally build that personal website I'd been thinking about. You know, the one every developer "should" have.

I spent few hours during the weekend setting up the project. Angular 17, the latest and greatest. I carefully planned the architecture, chose the tech stack, set up the repository, and selected HTML Template from marketplace and start the project. The dopamine hit was real – this was going to be amazing.

Then Monday came. Client work, deadlines, meetings. The personal site got pushed to "next weekend." Then next month. Then "when I have more time."

Here's the kicker though: I actually deployed the site in those early days of November 2023. It was live, functional, accessible via a URL. But I never shared it with anyone. Not a single person. Because it wasn't "perfect."

Over the next two years, I'd come back to the project sporadically. A weekend here, an evening there. I'd fix a bug, add a feature, tweak the styling. There was progress – slow, incremental progress. But the site remained my secret shame. The UI wasn't polished enough. There were accessibility violations. Performance could be better. The content needed work.

Fast forward to 2025, and that project had been sitting in this limbo for over two years. Not just unfinished – but finished enough to be embarrassing, yet not finished enough to be proud of. The worst kind of project purgatory.

The Starting Trap

This is actually worse than never starting at all. I had fallen into the "perfectionist's trap" – the project was functional but never "good enough" to share. It's the difference between:

Never starting: Clean slate, no guilt
Starting but never finishing: Haunting guilt, wasted effort
Finishing but never shipping: The worst of both worlds

I had fallen into the classic "starting" mindset:

Perfect timing fallacy: "I'll work on it when I have more time"
Perfectionism paralysis: "It needs to be perfect before anyone can see it"
Imposter syndrome: "Who am I to have a personal website?"
Feature creep: "Just one more improvement and then I'll share it"

The project wasn't just unfinished – it was psychologically blocked by my own impossibly high standards.

The Decision to Finish

Autumn 2025. I was scrolling through a Teams chat when I saw a message from a colleague to his team: "Stop starting, start finishing."

That sentence hit me like a lightning bolt.

I realized I had a backlog full of 80% complete projects, all waiting for that mythical "perfect moment" to be finalized. My personal website was just one of many casualties of this pattern. But it was the most visible one – literally sitting there on the internet, unloved and unshared.

That weekend, I made a decision. Not to make it perfect, but to make it done. To take it from "functional but hidden" to "good enough to share."

Here's what changed my approach:

AI as a finishing partner: With modern AI tools, those final polish tasks that used to take weeks could be done in hours. Accessibility fixes, performance optimizations, style improvements – tasks that previously felt overwhelming became manageable weekend work.

Redefining "done": Instead of "perfect," I defined done as "something I'm comfortable sharing." That's a much lower bar, but infinitely more achievable.

Time-boxing the work: I gave myself one weekend. Not "someday when I have time," but this specific weekend. Constraints breed creativity and prevent endless tinkering.

Embracing "good enough": The site didn't need to win design awards. It needed to represent me professionally and showcase my technical skills. Mission accomplished.

Those few weekend hours were genuinely fun. Instead of the overwhelming feeling of "this needs so much work," it became a focused sprint to the finish line. AI helped me polish styles, improve performance metrics, and fix accessibility issues that had been nagging at me for months.

Do You Actually Need a Personal Website?

Now that I've finally shipped mine, let me be brutally honest: Maybe not.

I know, I know. Every career advice article tells you that developers "must" have a personal website. But after going through this entire journey, I think that's oversimplified advice that doesn't consider individual circumstances.

When a Personal Website Makes Sense

You're experimenting with new technologies: This was my primary motivation. I wanted a playground to try modern Angular features – signals, zoneless change detection, SSG improvements, the new control flow syntax. Having a real project to experiment with is invaluable for learning.

You're building a personal brand: If you're consulting, speaking at conferences, or positioning yourself as a thought leader, a website gives you a professional home base that you control completely.

You enjoy the process: Some developers genuinely love building and maintaining their own sites. If tinkering with your personal project brings you joy, go for it.

You have unique content to share: If you're writing technical articles, showcasing projects, or have a story to tell that doesn't fit neatly into LinkedIn or GitHub, a website gives you the space and control to tell it properly.

You're job hunting and need differentiation: In a competitive market, a well-crafted personal site can help you stand out – but only if it's actually good and showcases relevant skills.

When You Probably Don't Need One

Your GitHub and LinkedIn tell the story: If your professional profile is already strong on existing platforms, a website might be redundant effort.

You're not maintaining it: A stale website with outdated information is worse than no website. If you won't commit to keeping it current, skip it.

You're doing it because you "should": Obligation is a terrible motivator for personal projects. If you don't have a genuine reason, you'll likely abandon it (like I almost did).

You're early in your career: Focus on building skills and shipping projects first. A website can come later when you have more to showcase.

You work in a specialized field: If you're in enterprise development, embedded systems, or other areas where personal branding isn't crucial, your time might be better spent elsewhere.

My Honest Assessment

For me, this website serves three specific purposes:

Technical playground: I can experiment with new Angular features in a real-world context (not only simple hello world app)
Learning documentation: Writing about what I learn helps solidify the knowledge
Professional presence: As someone who does consulting and speaking, it gives me a place to showcase expertise

But here's what it's NOT:

A magic career accelerator
A requirement for being a good developer
Something that will dramatically change my professional life

The Real Lesson

The value wasn't in having a personal website. The value was in finishing something I started.

That weekend when I finally polished and shared the site, I didn't just ship a website – I broke a pattern. I proved to myself that I could take something from "good enough to work" to "good enough to share." That mindset shift has been more valuable than the website itself.

Since then, I've applied the same "stop starting, start finishing" approach to other projects. I've cleaned up old repositories, published half-written articles, and shipped small tools that had been sitting in development limbo.

Your Decision Framework

Before starting a personal website, ask yourself:

What specific problem will this solve for me?
Am I willing to maintain it for at least a year?
Do I have something to share?
Will I actually finish it, or will it join my backlog graveyard?

If you can't answer these clearly, maybe start with improving your GitHub README files or writing on existing platforms first.