Building Before I Felt Ready: What My Side Projects Actually Taught Me

Building Before I Felt Ready: What My Side Projects Actually Taught Me

I have rarely felt completely ready at the beginning of a project.

Usually I knew enough to see the possibility and not enough to see all the problems. The comfortable option was to study a little longer, plan a cleaner version, or wait until I could describe myself with more confidence.

The moments that changed me came when the work began anyway.

This is not a story about every experiment becoming successful. Some changed direction. Some paused. Some taught me more through their friction than through their results. The common thread is that each real project exposed the next skill more clearly than preparation alone could.

“I learn by building” is not a polished slogan I added after everything worked. It is the pattern I can see when I look back.

ShopClues: responsibility arrived before confidence

I joined ShopClues as a trainee in March 2024.

At that point, my practical web-development base was HTML, CSS, Bootstrap and a small amount of JavaScript. I did not arrive feeling like a finished developer. I arrived with enough foundation to learn in context.

One of the first demands was PHP. I learned it in roughly a month and delivered my first project ahead of schedule.

The important lesson was not that a month is a universal timeline. It was that a real deliverable changes the way I learn. Documentation stops being a collection of topics and becomes a map for solving the problem in front of me. Feedback has consequences. Decisions have deadlines. “I understand this” becomes testable.

Responsibility created focus that a hypothetical exercise could not.

Later, I worked on a Qoo10 project through ShopClues using Next.js and TypeScript. That work pushed me into a different stack and a more structured way of thinking about interfaces. I was again learning while contributing, not finishing a perfect curriculum first.

Then the context changed. Qoo10’s financial crisis disrupted that chapter around September 2024, and ShopClues moved into a difficult phase with work-from-home changes and uncertainty.

I could not control the business environment. I could control whether the skills and habits from the work remained useful.

That distinction has stayed with me: a project can end without making the learning disappear.

The Vibed Vines: building a brand reveals more than designing one

The Vibed Vines was a dropshipping-brand experiment.

From a distance, an ecommerce brand can look like a visual exercise: choose a name, create a logo, build a storefront and publish products. The real experience connects many systems at once—positioning, product selection, suppliers, pricing, margins, customer expectations, content, acquisition and operations.

Building the brand forced me to move between design and business decisions. A page could look good and still fail to explain why somebody should trust the offer. A product could attract attention and still have weak economics. A campaign idea could be creative and still be difficult to sustain.

The experiment taught me to ask harder questions earlier:

• Who is this specifically for?
• What makes the offer different beyond presentation?
• What operational promise am I making?
• Can the margin support acquisition and support costs?
• What evidence would make a stranger trust the store?
• Does the system still work after the launch energy disappears?

The value was not only in the storefront. It was in seeing how many invisible decisions a storefront represents.

SmartStore: tools become useful when the workflow is clear

SmartStore came from thinking about systems and utility.

When I build a tool, it is tempting to begin with features. A dashboard can always hold another card. A form can always collect another field. AI makes it even easier to create the surface of a product before the workflow is settled.

The harder question is: what repeated job becomes easier because this exists?

That changed how I evaluated the idea. Instead of asking whether I could build a feature, I had to ask where it belonged in the user’s sequence, what information it required, and what decision it helped the user make next.

SmartStore reinforced three lessons:

1. a product needs a clear primary workflow before it needs a broad feature list;
2. structured data is valuable only when the structure matches real decisions; and
3. building the interface early is useful because it exposes vague thinking quickly.

Even when an experiment does not become a large product, it can improve the way the next product is framed.

Kraftt Digital: client work turns taste into accountability

Kraftt Digital brought a different kind of responsibility.

With a personal experiment, I can change direction because my curiosity changes. Client work has an external outcome. The website, content or system needs to serve a business that exists beyond my portfolio.

That changes the questions again.

What result matters to the client? Which audience needs to understand the offer? What can be maintained after handoff? Which part should be custom, and which part should remain simple? How do design, search, performance and conversion support the same goal instead of becoming separate checklists?

Kraftt taught me that taste is not enough. A strong opinion needs to survive constraints: budget, time, content readiness, technical limits and the client’s ability to use the result.

It also taught me that communication is part of the product. A technically correct decision has little value if I cannot explain the trade-off clearly enough for somebody else to choose it.

Unfinished work still needs an honest review

It is easy to turn every paused project into a motivational lesson after the fact. I do not want to do that.

Some projects paused because priorities changed. Some had an unclear business model. Some depended too heavily on launch energy. Some were more interesting to build than they were valuable to maintain. In a few cases, I moved to the next idea before I had built a proper distribution or feedback loop.

Those are not romantic details. They are weaknesses in the system.

The useful response is not to label every pause a failure or pretend it was the plan. It is to ask:

• What assumption remained untested?
• Did I stop because the evidence changed or because the work became repetitive?
• Was the scope too large for the available time?
• Did I define a finish line?
• Was there a real user and feedback loop?
• Which part deserves to be reused?

An unfinished project becomes useful when its lesson changes the next decision.

The lessons that transferred

Readiness often follows exposure

I still prepare. I read documentation, make plans and study examples. But I no longer expect preparation to remove uncertainty.

Real work exposes the unknowns that matter. A deadline shows whether I can prioritize. A deployment shows whether I understand the environment. A client conversation shows whether I understand the problem. A customer question shows where the explanation failed.

Confidence built from exposure is quieter than confidence built from theory. It does not mean I know everything. It means I have a process for finding the next answer.

Shipping reveals the next skill

Before launch, it is easy to believe the missing skill is more coding or a better design. After launch, the real gap might be positioning, distribution, documentation, analytics, support or maintenance.

Shipping makes the bottleneck visible.

That is one reason I want ketangoyal.me to include build logs, not only finished case studies. A build log can show what the project demanded at each stage, including the parts that were not obvious at the beginning.

Systems matter after motivation falls

Starting is emotional. Continuing is operational.

The projects that move forward need a repeatable next step: a publishing workflow, a task list, a deployment process, a customer-feedback habit, a content calendar or a review checkpoint.

Motivation can create momentum, but a system decides whether the work survives an ordinary week.

Evidence is stronger than a title

I am not trying to position myself as someone who has solved every category I write about. My authority should come from what I can show: the date, the tool, the decision, the build, the failure, the test and the lesson.

That makes writing more demanding. It also makes it more useful.

“I know ecommerce” is a broad claim. “Building The Vibed Vines taught me that a polished storefront cannot compensate for weak offer economics” is a specific observation that can be questioned and applied.

Not every experiment deserves to continue

Persistence is valuable, but continuation is not automatically virtuous.

A project can be paused because the evidence is weak, the opportunity cost is high or the problem no longer feels worth solving. The discipline is to make that decision consciously, record what was learned and avoid carrying unnecessary guilt into the next build.

Stopping a project and abandoning the habit of building are not the same thing.

What I am building now

This website is becoming the place where I connect these threads: technology, businesses, systems and experiments.

The Writing section is part of that. Sanity gives me a structured place to publish articles and images. Next.js turns the content into the public site. GitHub Pages keeps the deployment static, which means publishing includes a deliberate rebuild. The categories make the territory clear without pretending every post fits into one narrow identity.

I want the work here to remain specific:

• Websites & Search for practical discovery and website decisions;
• AI & Building for experiments with tools and product workflows;
• Prompting & Systems for repeatable ways of working; and
• Experiments & Lessons for the parts that only make sense in retrospect.

The site is not proof that the journey is complete. It is a better record of the journey while it is happening.

Build before certainty, review after evidence

“Start before you are ready” can sound careless if it means ignoring risk or refusing to learn the fundamentals.

What it means to me is narrower: do enough preparation to take a responsible next step, then let the work reveal what the next step actually is.

Build a small version. Put it in front of reality. Keep the evidence. Review it honestly. Improve the system. Continue when the problem still deserves the effort.

I am still learning how to do that well.

But when I compare the skills I had before ShopClues, the questions I asked before The Vibed Vines, the way I framed SmartStore, and the responsibility I now bring to Kraftt Digital, the pattern is clear.

I did not become ready and then build.

Building is how readiness began.

See the work behind the lessons. Explore the projects and build notes on ketangoyal.me/builds (/builds), or visit Kraftt Digital (https://krafttdigital.in/) to see how the learning is being applied to real digital work.