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.

Hero section.

About me.

Tech stack.

Projects.

Contact button.

Done.

It looked good, but there was one problem:

It didn't really do anything.

It was basically a resume with animations.

A portfolio should compound

If you're constantly building things, your portfolio shouldn't remain a static page that you update every six months.

It should grow with you.

I wanted mine to become a place where someone could understand not only what technologies I know, but what I actually do.

That meant showing:

• products I've shipped

• tools I've built

• technical decisions I've made

• things I've written

• certifications and credentials

• resources I recommend

• experiments I'm currently working on

The goal shifted from:

“Here are my skills.”

to:

“Here is evidence of how I work.”

That is a much stronger signal.

Projects need context

A screenshot and a list of technologies don't tell someone very much.

Next.js
TypeScript
Supabase
Tailwind CSS

Cool.

But why did I build it?

What problem did it solve?

What decisions did I make?

What broke?

Did anyone use it?

What did I learn?

Those questions tell you more about a developer than a technology badge ever will.

So instead of treating projects as gallery items, I've started treating them as small case studies.

The stack is still there.

It just isn't the story.

Writing became part of the portfolio

This was another thing I underestimated.

A repository can show that you can code.

Writing can show how you think.

If I write about an architecture decision, failed product experiment, UI problem, or something I learned while building, someone can understand my reasoning without ever meeting me.

That matters.

Especially when a lot of developers increasingly have access to the same frameworks, AI tools, templates, and components.

Knowing why you made a decision becomes more valuable than simply proving you know the syntax.

Small tools are surprisingly useful proof

Not everything needs to become a startup.

Sometimes I notice a small problem and build a tool around it.

Those projects may only take a day or a weekend, but they show something larger:

Can you identify a problem and ship a usable solution without turning it into a six-month project?

That's a skill I want my portfolio to demonstrate.

So I started giving those smaller tools a real place alongside larger products.

Distribution matters too

Another mistake I made early was assuming people would somehow find my website.

They usually won't.

A portfolio works better when it becomes the center of a larger identity graph.

My website connects to places where different parts of my work already live:

• GitHub for code

• LinkedIn for professional work

• Product Hunt for products

• Hashnode for technical writing

• Devpost for hackathons

• design platforms for UI work

• startup platforms for founder profiles

• social platforms for ongoing ideas and builds

The website is the canonical source.

Everything else distributes pieces of it.

GitHub ─────┐
LinkedIn ───┤
Hashnode ───┤
Product Hunt ──→ Portfolio
Devpost ────┤
Socials ────┘

Instead of asking one website to generate all of my visibility, each platform reinforces the same identity.

My portfolio is never really finished

I rebuild my portfolio regularly.

Not because changing gradients is productive.

Because what I want the website to represent keeps changing.

At first, I wanted it to say:

I can code.

Later:

I can build full-stack applications.

Now I want it to communicate something closer to:

I can identify problems, design systems, build products, ship them, and explain the decisions behind them.

That's harder to represent.

But it's also much closer to the developer I actually want to become.

You can see the current version at jansencadorna.com.

I'll probably rebuild parts of it again.

That's kind of the point.