I Started Coding at 12. Eventually, Writing Code Stopped Being the Hard Part.

I started programming when I was 12.

Back then, my idea of becoming good at tech was pretty straightforward:

Learn more languages. Build more projects. Get better at writing code.

For years, that mostly worked.

I learned by building. Websites, small tools, experiments, freelance projects, hackathons—anything that gave me an excuse to figure something out.

I became comfortable with breaking things, reading documentation, debugging for hours, and learning whatever technology a project required.

At some point, though, I realized something:

Writing the code was becoming the easy part.

The harder questions were everything around it.

Building something is different from building something useful

A project can have clean architecture, a polished UI, and an impressive stack while solving almost nothing.

I've built enough things now to notice the difference.

The questions I care about more today are:

• Does anyone actually need this?

• Can someone understand it without me explaining it?

• What should I remove?

• What is the smallest version worth shipping?

• Where will users come from?

• Why would they return?

• Is this technically impressive, or actually useful?

Those questions changed how I approach software.

I still care deeply about engineering. But I no longer see code as the finished product.

Code is the implementation layer.

I started thinking more like a product builder

Over time, my work expanded beyond development.

I started caring about UI/UX because technically correct software can still feel terrible to use.

I started learning product strategy because shipping features without knowing why they exist creates bloated products.

I started paying attention to distribution because the best product nobody discovers is still a product nobody uses.

And after attending hackathons, startup events, meeting other builders, and talking to actual users, another assumption broke:

Being technically capable isn't enough on its own.

You need to communicate.

You need to meet people.

You need to understand problems outside your own perspective.

You need to put your work somewhere other than localhost.

What I'm building now

Today, most of my work sits somewhere between engineering, product, design, and startups.

I'm building Abstruck, a learning and knowledge workspace focused on turning information into something people can actually understand and use.

I'm also building ShipBits, alongside smaller developer tools, experiments, and commissioned projects.

My stack changes depending on the problem, but I spend a lot of time with Next.js, React, TypeScript, Supabase/PostgreSQL, Python, Tailwind CSS, AI integrations, and modern web tooling.

The technology matters.

But increasingly, I'm more interested in why a system is designed the way it is than simply what framework powers it.

I'm still learning in public

I don't have a polished story where everything suddenly clicked.

I'm still in college.

I'm still shipping things that fail.

I still rewrite code I thought was good six months ago.

I still have ideas that sound great until actual users interact with them.

That is probably the most useful part to document.

So I'll use this publication to write about what I'm actually doing:

• building SaaS and AI products

• full-stack engineering

• product and architecture decisions

• UI/UX

• experiments that worked or failed

• startup lessons

• tools and resources I find useful

• what I learn while shipping

Not as someone who has everything figured out.

Just as someone who keeps building enough things to keep finding better questions.

My work lives at jansencadorna.com.

This is where I'll document the parts between the commits.