SHIP
Build It. Finish It. Put It Out There.
I've never really been afraid of showing people what I build.
Actually, I do the opposite.
I look for opportunities to showcase myself.
Competitions. Projects. Opportunities to demonstrate what I can do.
Even when there's a chance things might go badly, I still want to try.
Because I'd rather put myself out there and find out what happens than keep wondering what might have happened if I had tried.
But over time, I've realized something.
Showing your work isn't the same as finishing it.
You can have an idea.
You can build something.
You can put it online.
And you can still have a long way to go before it's truly ready.
That's where shipping becomes interesting.
Not the moment you make something visible.
But the moment you decide it's ready to leave your hands.
"The courage to show your work gets you noticed. The discipline to finish it gives people something worth noticing."
THE THINGS I'VE PUT OUT THERE
I've shipped things.
My personal website,
Rahi.
Each represents something I wanted to create and made available for others to see.
But there's a detail worth mentioning.
Arvexa and Rahi were deployed in earlier versions, not their final builds.
And I think that's an important distinction.
Putting something online doesn't automatically mean you've finished it.
A deployment means the thing exists somewhere other people can access it.
Finishing means you've met the standard you originally set for it.
Those are two different milestones.
I've experienced both.
And I've learned not to confuse them.
"Making something available is a milestone. Making it ready is a responsibility."
WHEN IS SOMETHING ACTUALLY FINISHED?
For me, the definition used to be simpler.
If the thing I planned to build existed, worked, and served its intended purpose, I could consider it finished.
And honestly, that is still an important part of the definition.
If I set out to build something, I want to build what I intended.
Not a random collection of features.
Not something that merely resembles the original idea.
The actual thing.
Working.
Professional.
Ready to release.
But my understanding has evolved.
Now I think about what happens after the project leaves my hands.
Can it handle the people who will use it?
Is the experience clean?
Is the architecture appropriate?
Can it scale if it needs to?
Are there obvious errors?
Is it easy to understand?
Does it actually solve the problem without creating unnecessary ones?
The answer depends on what I'm building.
A small personal experiment doesn't need the same level of polish as an application a client will depend on.
A production product needs more than a screen that looks good and a feature that works on my machine.
The definition of finished depends on the responsibility the project carries.
"A project isn't finished when you've exhausted your ideas. It's finished when it meets the standard required of it."
And that standard matters.
NOT EVERY PROJECT NEEDS TO BE PERFECT
I don't believe every project needs to be polished to perfection before it can be released.
That would be ridiculous.
Imagine treating a small experiment as if thousands of people were depending on it.
You'd spend more time preparing to build than actually learning from building.
For a personal experiment, I'm comfortable with something rough around the edges.
It might have fewer features.
The interface might not be beautiful.
Parts of the implementation might need improvement.
As long as it serves its intended purpose and is safe and appropriate for its intended use, it can still be worth releasing.
Sometimes the point is to test an idea.
Sometimes it's to learn a technology.
Sometimes it's simply to see whether something is possible.
But the expectations change when other people depend on the result.
A client application should be professional, intuitive, reliable, and easy to use.
A product intended for real users also needs careful attention to architecture, scalability, user experience, and the possibility that things will go wrong.
The stakes are different.
The standards should be different too.
"Don't demand production-level perfection from an experiment. Don't deliver experiment-level quality to someone who depends on your product."
Knowing the difference is part of becoming a better builder.
THE PROJECT I KEEP REFINING
There is one project that makes this distinction particularly relevant.
CORVEX.
I'm working on security and attack-chain discovery tooling, and I keep refining it.
Improving things.
Revisiting decisions.
Looking at what could be better.
Trying to get it closer to what I want it to become.
And I haven't released it yet.
The reason is simple.
I don't feel it's there yet.
I want it to be better before I put it out into the world.
There is nothing inherently wrong with that.
Some projects genuinely need more work before they're ready.
Especially when the quality of the result matters.
But there's a question I have to keep asking myself:
Am I improving the project because it genuinely needs improvement?
Or am I moving the finish line every time I get close to it?
Those questions can look almost identical from the outside.
Both result in more development.
Both can produce a better product.
But one moves the project toward release.
The other can keep it in development indefinitely.
"Refinement is valuable when it closes the gap between what exists and what is required. It becomes a trap when the definition of 'ready' keeps moving."
I don't have a universal answer to that problem.
I just know it's something worth watching.
Because I don't want to spend so long making something better that nobody ever gets to use it.
THE USER GETS A SAY
When someone uses something I've built, I care about their reaction.
But not only whether they like it.
I care about their difficulties.
Where they get stuck.
What feels confusing.
What they expected to happen.
What they suggest improving.
What could be refined.
Because I can spend days building a feature that makes perfect sense to me.
I know how it works.
I know where everything is.
I know what each button does.
But the person using it doesn't have the same understanding.
They arrive with their own expectations.
Their own habits.
Their own problems to solve.
And sometimes the thing that seems obvious to me isn't obvious to them at all.
That's useful information.
It shows me the difference between what I intended to build and what someone actually experiences.
"The developer knows how the product was built. The user reveals whether it was built well."
I don't want to build something just to say I built it.
I want it to do what it was supposed to do.
And if the person using it struggles, I want to understand why.
Sometimes the solution is a better interface.
Sometimes it's clearer communication.
Sometimes it's a technical change.
Sometimes the feature itself needs rethinking.
Shipping doesn't end the learning process.
In many ways, it gives you access to information you couldn't get while the project was still sitting on your laptop.
THE BUG I FOUND AFTER RELEASING
I've experienced that firsthand.
Remember the workload balancer I built for my school?
I made an architectural mistake.
The data was stored in the browser's local database.
The application appeared to work, but the data couldn't be shared properly between the people who needed it.
I realized the problem too late.
And I had to fix it in a later update.
That experience made one thing clear.
A project can look finished while still carrying a serious flaw.
I could have convinced myself that the feature worked.
I could have looked at the interface, tested the obvious interactions, and decided everything was fine.
But the application had a requirement that went beyond what I had initially implemented.
The data needed to be shared.
The architecture didn't support that requirement.
And no amount of visual polish could solve the underlying problem.
It required a technical correction.
"Polish cannot compensate for an architecture that fails to meet the product's actual requirements."
That mistake changed how I think about readiness.
I still believe in releasing things.
But I also believe in understanding what you're releasing, who will depend on it, and what can go wrong.
Speed matters.
So does judgment.
PLAN. THEN START.
I don't dislike planning.
Quite the opposite.
I think planning is one of the best things you can do before attempting something meaningful.
It helps you understand what you're trying to accomplish.
It gives you direction.
It exposes dependencies.
It helps you identify what you need to learn.
But there is one thing planning cannot do.
It cannot show you every problem that will appear during execution.
You can think through an idea for weeks and still discover something unexpected within the first hour of implementation.
A technology behaves differently than you expected.
A dependency creates a problem.
The architecture needs to change.
A feature turns out to be more complicated than you imagined.
A real user wants something you never considered.
And suddenly, your beautiful plan needs to be revised.
That's why I believe in planning and starting execution as soon as reasonably possible.
Not recklessly.
Not without thinking.
But without pretending that planning can eliminate uncertainty.
"Planning gives you a map. Execution reveals the terrain."
You need both.
A plan without execution remains hypothetical.
Execution without planning can create unnecessary chaos.
The real skill is knowing when you have thought enough to begin—and being willing to change your plan when reality teaches you something new.
THE REASONS I DON'T FINISH EVERYTHING
Not every project I start gets finished.
Sometimes I run out of time.
Sometimes I lose interest.
Sometimes I realize the project isn't worth continuing.
And those are different problems.
Time is a constraint.
Interest can change.
And the value of an idea can become clearer as you work on it.
I don't think every project deserves to be completed simply because I started it.
That would mean treating the time already invested as more important than the value of the result.
Sometimes the right decision is to stop.
Sometimes it is to simplify the idea.
Sometimes it is to put the project aside and return to it later.
And sometimes, honestly, I just need to manage my time better.
The important thing is to understand which situation I'm dealing with.
Because there is a difference between abandoning a project after learning that it isn't worth pursuing and abandoning it every time the work becomes difficult.
One is a decision.
The other can become a habit.
"Finishing everything isn't the goal. Knowing what deserves to be finished—and following through on it—is."
I want to get better at making that distinction.
SHIPPING ISN'T THE END
I think one of the biggest misconceptions about releasing a project is that it represents the end of the work.
Sometimes it does mark the end of a development phase.
But for something people actually use, it can also mark the beginning of a different kind of responsibility.
Now you can see how the product behaves outside your own environment.
You can discover problems you didn't anticipate.
You can listen to feedback.
You can observe where people struggle.
You can improve the experience.
You can make the architecture more robust when the need arises.
You can decide which features are worth adding and which ideas should remain ideas.
The work changes.
It doesn't necessarily stop.
And that's okay.
I don't expect every project to emerge perfect.
I expect it to meet the standard required for its release—and to give me a foundation I can improve when improvement is necessary.
"Release is not a declaration that nothing can be improved. It is a declaration that the work is ready for its next stage."
That's a much more useful definition of shipping.
SHIP
Build It. Finish It. Put It Out There.
I've never wanted to hide everything I build until I become good enough.
I want to put myself out there.
I want to find opportunities.
I want to see what happens when my work meets the real world.
Sometimes I'll get things wrong.
Sometimes I'll release something and discover a mistake.
Sometimes I'll realize the idea needs to change.
Sometimes I'll look back at an earlier version and wonder what I was thinking.
That's part of the process.
But I also want to be responsible about what I release.
I want personal experiments to teach me something.
I want client applications to meet the expectations of the people trusting me.
I want products intended for real users to be built with the reliability, usability, and architecture they require.
I want to listen when people struggle.
I want to improve what needs improving.
And I want to know when a project is genuinely ready instead of endlessly chasing an imaginary version of perfection.
Because building something is only part of the work.
Finishing it means making the thing you intended to make.
Shipping it means letting that work stand outside your own world.
And improving it means being willing to learn from what happens next.
I'm still learning how to do all three better.
But I'm not waiting until I know everything.
I'm building.
I'm releasing.
I'm listening.
I'm refining.
And when something is ready—
I'll put it out there.