There was a time when, for me, building a website mostly meant getting a page to look right.
A navigation bar at the top. A hero section. A few cards. Some images. A contact form.
If everything looked good on a phone and a laptop, I considered the job more or less done.
Over time, that changed.
I started becoming more interested in what happens beyond the interface — how the frontend communicates with a backend, how data moves through an application, how authentication works, how different parts of a system fit together, and what makes an application reliable after it has been deployed.
That shift, from building websites to building applications, has probably been one of the biggest changes in my development journey.
Where I Started
Like many developers, I started with the basics.
HTML, CSS and JavaScript were the first technologies that helped me understand how websites actually worked. At first, I was mostly interested in the visual side of things. I wanted to know how to recreate interfaces I liked and make my own pages look better.
Then came JavaScript.
That was when things became more interesting.
I could finally make the pages I was building respond to users. Forms could do something. Buttons could trigger actions. Data could be manipulated instead of simply displayed on a page.
Eventually, I moved into React.
React changed the way I thought about frontend development. Instead of thinking about a page as one large piece of HTML, I started thinking about interfaces as collections of smaller, reusable components.
That shift sounds simple now, but it changed quite a lot about how I approached development.
From Pages to Components
One of the things I appreciate about React is that it encourages you to think about the structure of an interface.
Instead of asking:
"How do I build this page?"
I started asking:
"What are the different pieces that make up this page?"
A navigation component.
A reusable button.
A form.
A table.
A card.
A modal.
A dashboard widget.
Those pieces can then be reused and composed into larger interfaces.
As the projects I worked on became more complicated, this way of thinking became increasingly useful.
I was no longer just building individual pages. I was building systems made up of many interconnected pieces.
When Websites Started Becoming Applications
The real change happened when I started working on projects that needed to do more than present information.
A business website is one thing.
A business application is another.
Once users need to log in, submit information, retrieve data, update records, interact with different workflows, or have different permissions, the frontend becomes only one part of a much larger system.
This is where I started paying more attention to APIs and backend systems.
The frontend might have a form, but where does that information go?
A dashboard might display a list of records, but where does that data come from?
A user clicks "Approve". What happens after that?
A user should only see certain information. Where is that permission enforced?
These questions made me realise that being a good frontend developer isn't only about writing good UI code.
You need to understand the environment your frontend lives in.
Learning to Work With APIs
Working with APIs was one of those areas that pushed me beyond the traditional idea of frontend development.
At first, an API can seem quite abstract.
You make a request, you get some JSON back, and you display it.
But real applications aren't always that straightforward.
You have to deal with loading states.
Errors.
Empty responses.
Authentication.
Pagination.
Caching.
Invalid data.
Network failures.
Mutations.
Optimistic updates.
And, most importantly, the experience the user gets while all of this is happening.
That changed how I approached frontend development.
I stopped thinking only about what happens when everything works.
I started thinking about what happens when something doesn't.
Working With Real Projects
Another major part of my growth has come from working on real projects.
There's a big difference between building something for practice and building something that someone actually depends on.
In a personal project, if something breaks, you can fix it when you have time.
In a real project, there might be a client waiting for it, users depending on it, a deadline approaching, or another developer waiting for your changes.
Real projects also introduce constraints that tutorials don't always prepare you for.
Sometimes you have to work with an existing codebase.
Sometimes the design isn't perfect.
Sometimes the API behaves differently from what you expected.
Sometimes requirements change halfway through development.
Sometimes you inherit code that you didn't write.
And sometimes the solution that looks perfect technically isn't the right solution for the business.
I've learned a lot from those situations.
CEMES Has Been Another Step Forward
My work at CEMES has also contributed significantly to this shift in how I think about development.
Working on an enterprise application has exposed me to a different side of software development.
The frontend isn't an isolated website.
It has to communicate with backend services, respect permissions and workflows, handle real business processes, and fit into a larger development environment.
I've worked with React and TypeScript on the frontend while integrating with ASP.NET APIs and working within an Azure DevOps workflow.
That experience has reinforced something I've gradually learned over the years:
The interface is only one part of the product.
A good frontend still needs good architecture, reliable data, sensible error handling, maintainable code and an understanding of the business problem it's solving.
I'm Still a Frontend Developer
Interestingly, learning more about the rest of the stack hasn't made me want to move away from frontend development.
Quite the opposite.
It's made me appreciate frontend development more.
When you understand what happens behind an API request, you can design the frontend around it better.
When you understand databases and backend workflows, you can ask better questions.
When you understand deployment and performance, you make better technical decisions.
And when you understand the business problem, you stop treating the UI as the entire product.
I still enjoy building interfaces.
I enjoy taking a design and turning it into a working application.
I enjoy figuring out how components should be structured.
I enjoy making a page responsive.
I enjoy the small details that make an interface feel polished.
But now I'm interested in the bigger picture as well.
What I'm Learning Now
I'm still learning.
There are areas of software development that I'm much more comfortable with than I was a few years ago, and there are plenty of areas where I still have a lot to learn.
Right now, I'm particularly interested in going deeper into:
- Full-stack application development
- Better frontend architecture
- TypeScript
- API design and integration
- Application performance
- AI-powered applications
- Mobile development
- Building products rather than just pages
I'm not trying to learn every technology that comes out.
I've become more interested in understanding why a technology exists, where it fits, and whether it actually solves a problem.
What Building Applications Has Taught Me
If there's one thing this journey has taught me, it's that becoming a better developer isn't simply about learning more technologies.
It's about learning to think about problems differently.
A website can look beautiful and still be poorly built.
An application can have an impressive technology stack and still provide a terrible user experience.
And a technically elegant solution can still be the wrong solution if it doesn't solve the actual problem.
The more I build, the more I appreciate the balance between design, engineering, users and business requirements.
That's probably what I find most interesting about software development today.
What's Next?
I don't think the transition from building websites to building applications has an exact finishing point.
There's always another problem to solve and another part of the stack to understand.
For me, the next stage is about becoming a more well-rounded developer while continuing to build on the frontend skills I've developed over the years.
I want to build applications that aren't just visually good, but are reliable, maintainable and genuinely useful.
The websites I built when I was starting out taught me how to build.
The applications I'm working on now are teaching me how to build things that matter.
And I think that's a much more interesting journey.
Thanks for reading.
If you're interested in frontend development, React, Next.js, TypeScript, or the process of building modern web applications, you can explore more of my articles or take a look at some of the projects I've worked on.
