#BUILD100 Manifest
TL;DR
#BUILD100 is my personal challenge to release 100 software projects before the end of 2026.
It is designed to attack three weaknesses I have as a software engineer when it comes to building my own products: I overthink instead of releasing, my experience is wide but not packaged into a product skill, and agentic development is moving faster than my habits.
If any of that sounds familiar, this manifest might be useful for you too.
Who I am
I am a software engineer with 15 years of experience.
Two things have always pulled me: I love learning new technologies, and I love building products.
The first I get to do every day. The second is where I get stuck.
For the last five years I have been trying to ship my own products — and I have been failing. Not because of code. Not because of technologies. The problem was somewhere else.
There are three things I want to change.
Problem 1: I overthink instead of releasing
Every time I tried to build my own projects, the same loop appeared: perfectionism, procrastination, endless architecture.
I would spend weeks thinking about the perfect stack, the perfect domain model, the perfect infrastructure, the perfect design, the perfect workflow.
But a perfect plan that never ships is still zero.
I even tried to solve this by creating more free time. Twice, I took around three months during summer without a regular job so I could focus on my own products.
It did not work.
I burned out, overthought everything again, and still did not release what I wanted to release.
The first thing I want to change is this pattern. I want to stop optimizing plans and start releasing products.
Problem 2: my experience is wide, but not packaged into a product skill
Over these 15 years I worked across frontend, backend, DevOps, system design, architecture, QA, project management, leadership, security, design, and even some marketing and product discovery — in domains like telecom, payment systems, blockchain, and fintech.
I am not an expert in every one of these areas. But I do have a broad overview of how software, teams, systems, and products are built from many different angles.
And yet, knowing many separate parts of the process is not the same as having a repeatable product development skill.
I want to compress that experience into a clear end-to-end loop: discovery, product thinking, design, implementation, testing and QA, deployment, iteration, distribution, and marketing.
A repository can be technically complete and still not be a product. A product needs a clear idea, a user-facing result, a way to reach people, feedback, and iteration.
The second thing I want to change is this gap. I want to turn fragmented experience into a single, end-to-end product skill.
Problem 3: agentic development is moving faster than my habits
When the AI era started, I thought: "Now this is it. I will create an army of agents, and they will build products for me."
The same pattern repeated. Instead of shipping products, I started overengineering the AI workflow itself. More agents. More architecture. More systems around the system.
AI can make development faster, but it does not automatically make you a builder. If your default pattern is overthinking, AI will help you overthink faster.
And the field itself is moving faster than my habits. New tools, frameworks, models, editors, agents, and patterns appear all the time. I want to keep up — but I cannot safely test every new approach on serious production projects.
The third thing I want to change is the way I work with these tools. I need a real playground to compare agentic workflows on real artifacts, not just on hello-world demos.
The challenge
These three problems led me to #BUILD100.
The format is intentionally uncomfortable.
100 projects by the end of 2026 means about two days per project on average. That leaves very little space for perfectionism. It forces decisions. It creates repetition. It turns learning into real artifacts.
For a project to count, it has to hit three criteria:
- Released. Not perfect, not polished, not architecturally beautiful. Released.
- Goes through the full product loop. Not just the coding part. Discovery, design, implementation, deployment, distribution.
- Built with an agentic AI workflow. Every project doubles as a playground for testing AI tools, agents, and patterns on real artifacts.
These three criteria map directly to the three muscles I want to train, in the same order of priority: builder, product development, agentic workflow.
The builder muscle is non-negotiable.
If a project is not released, it does not count. No matter how interesting the product loop was. No matter how clever the agentic workflow turned out.
Released first. Everything else is a bonus on top.
Why I am doing it publicly
I have already tried the private versions of this: motivation, free time, money pressure, quitting regular work for a few months.
None of them solved the core problem. Doing the same thing and expecting a different result is the definition of insanity, so this time I am changing the format.
#BUILD100 is build in public.
Public work creates visibility. Visibility creates accountability. Accountability changes the game.
Another reason I want to do this publicly is that I have spent too many years building things mostly inside my own head.
Ideas, systems, architectures, products — many of them never became real artifacts that could exist outside of me.
I want to change that.
I want to leave visible traces behind: projects, experiments, posts, videos, mistakes, iterations.
Not only to improve as a builder, but also to reconnect with the outside world through creation.
What I will share
During this challenge, I will share:
- released projects and their iterations;
- open-source code for most of them;
- implementation notes and technical decisions;
- AI and agentic workflow experiments;
- product development insights;
- mistakes and lessons from shipping quickly.
The goal is to leave a public trail of real attempts, not just polished success stories.
Why this can be useful for you
If you watch or read this series, you will see:
- real projects going from idea to release;
- how I move through the full product loop, not only the coding part;
- how I use AI and agentic workflows on actual products, not toy examples;
- what actually works and what wastes time.
And if you have a similar pattern — too much overthinking, too little releasing — maybe this format will give you a starting point for your own version.
It does not have to be 100 projects. It just has to force you to release.