DEV Community: Deolawage

I Built MarkDump During SIWES: My Experience Building a Marketplace with JavaScript.

Deolawage — Thu, 15 Oct 2026 15:50:58 +0000

My experience building a marketplace with vanilla JavaScript and Afribase during my Students Industrial Work Experience Scheme.

Hello, Earth!

During my Students Industrial Work Experience Scheme (SIWES), I worked on a project called MarkDump, an online marketplace where users can upload products for others to browse.

The idea was straightforward: build a marketplace where people could list their products, discover items, and eventually buy and sell through the platform.

I was the only developer working on it, using HTML, CSS, and vanilla JavaScript for the frontend. For the backend, I eventually settled on Afribase.

It sounded like a straightforward project when I started thinking about the features.

A product form. A product grid. A cart. A wishlist. A database to store everything.

But this was my first time working on something like this, and I quickly realised that knowing how to build individual features was different from putting an entire application together.

There was a lot to figure out, and one of my biggest challenges wasn't even the backend.

It was organising my JavaScript.

Starting with the frontend
I started with the part I was more familiar with: the interface.

I worked on the navigation, hero section, product grid, and different sections of the homepage. I also built a modal where users could enter product details and upload product images.

Gradually, MarkDump started looking like an actual marketplace.
Products had somewhere to appear. The form had somewhere to collect information. The interface was beginning to take shape.

But making a website look like a marketplace and making it function like one are two different things.

I needed to figure out how the product data would be managed, how the form would work, and how products would move from the form into the database and back onto the page.

Then there were other features to consider, such as the cart and wishlist.
Each feature introduced new logic, and I had to think about how it would fit into the application.

That was when I began to appreciate how much thought goes into building something beyond its appearance.
My biggest challenge: organising the JavaScript
This was probably the most challenging part of building MarkDump.
As I added more features, I had to think carefully about where the different pieces of JavaScript should live and how they should communicate.

I didn't want everything sitting in one enormous file with functions doing unrelated things.
I started exploring different approaches to organising my code, including classes, factory functions, and the module pattern.

I created a Product class to represent products and a ProductManager to handle product-related operations. I also worked on a DisplayController to handle rendering products on the page.
Each part had a responsibility.

The product representation didn't need to worry about how a product card looked in the browser. The display logic didn't need to handle every aspect of managing product data.
At least, that was the direction I wanted to take.

The difficult part was figuring out how to make these pieces work together without making the application unnecessarily complicated.

Sometimes, I had to stop and reconsider how I had structured something. Other times, I needed to think through which part of the application should be responsible for a particular operation.

I was learning the concepts while trying to apply them to a real project.

That made the experience different from simply reading about JavaScript classes or factory functions.

Instead of only asking myself what a particular concept meant, I had to ask questions like:

Does this functionality belong in this class?
Should this module be responsible for managing the data or displaying it?
How should these parts communicate?
Am I making this unnecessarily complicated?

I didn't always have immediate answers.
But I kept working through the problems.
MarkDump taught me that knowing JavaScript syntax and knowing how to organise an application are two different skills.

I'm still developing both, but building this project gave me a reason to think more deeply about the second one.

**
Connecting the frontend to Afribase**

Once I had the frontend taking shape, I needed somewhere to store product data.
I eventually chose Afribase and set up a database table for products.

Afribase is a backend and hosting platform that provides developers with tools such as PostgreSQL databases, authentication, and file storage without having to assemble every part of the backend infrastructure themselves. Afribase
It's also a relatively new platform, currently in beta, which made trying it out an interesting part of my experience. Afribase
I chose Afribase for MarkDump because I needed a way to store product information and retrieve it from my frontend.

I created a database table for products, with fields for the product name, description, price, category, quantity, images, seller, location, and creation date.

Then I connected my JavaScript application to the database.
I tested the connection, queried the products table, and eventually managed to insert a product successfully.
Seeing that work was satisfying.

The product information wasn't just sitting in a JavaScript object anymore. I could send it to the backend and store it in the database.

You can check out Afribase here: https://useafribase.app/.
But getting the database connection working was only one part of the process.

I still needed to make sure the application could save products, retrieve them, and display them correctly.

That meant thinking about the entire flow:

A user enters product information.
The application collects that information.
The data is sent to the backend.
The database stores it.
The application retrieves the product and displays it in the marketplace.

Every step matters.
If a product is saved successfully but doesn't appear on the page, something still needs investigating. If the application retrieves the product but the display logic doesn't handle the data correctly, the user still won't see what they expect.
Working through these different parts helped me understand why connecting a frontend to a backend involves more than simply making a request.

The different pieces have to work together.

The records included information such as the product name, description, price, category, quantity, images, seller, location, and creation date.

Then I had to connect the application to the database.
I tested the connection, queried the products table, and eventually managed to insert a product successfully.
Seeing that work was satisfying.

The data was no longer limited to what I had manually created in JavaScript. I could send product information to the backend and store it in the database.

But getting the connection working was only one part of the process.

I still needed to make sure the application could save products, retrieve them, and display them correctly.
That meant thinking about the entire flow:
A user enters product information.

The application collects that information.
The data is sent to the backend.
The database stores it.
The application retrieves the product and displays it in the marketplace.

Every step matters.
If the product is saved successfully but doesn't appear on the page, something still needs investigating. If the application retrieves the product but the display logic doesn't handle the data correctly, the user still won't see what they expect.

Working through these different parts helped me understand why connecting a frontend to a backend involves more than simply making a request.

The different pieces have to work together.
Getting familiar with asynchronous JavaScript
Connecting MarkDump to Afribase also meant working with asynchronous JavaScript.

I had to start understanding how async and await fit into the application and how database operations affect the flow of execution.

For example, retrieving products from the backend takes time. The application needs to account for that before trying to use the returned data.
This became particularly important when working with product-related operations.

I had to think about when data would become available, where I needed to wait for a result, and how the rest of the application should respond.
I was learning these concepts while implementing them, so there was a lot to think through.

What I appreciated was that I wasn't learning asynchronous JavaScript in isolation. I had an actual reason to understand it.
I needed it to help MarkDump work.

And that made the concepts more meaningful to me.
What MarkDump can do right now
MarkDump isn't finished yet, but it isn't just a static design either.

At its current stage, users can:

Upload products to the marketplace.
Browse available products.
Add products to their cart.
Add products to their wishlist.

These are working parts of the application that I've had to build and connect.

There are also features I haven't completed yet, including:

User authentication.
Payments.
Order management.
Drops. And the UI needs a bit, more work.

I still have work to do before MarkDump can offer the complete experience I originally envisioned.
I'm mentioning this because I don't want to present the project as something it isn't.

Building an application involves making progress, identifying what's missing, and continuing to work towards the intended result.

MarkDump is still a work in progress, and I'm learning from that process.

The biggest lesson: this was my first time
Looking back, what stands out most isn't one particular feature or a single moment when something finally worked.
It's the experience of working on an application like this for the first time.

Before MarkDump, I could learn a concept, practise it, and move on to the next lesson.

With this project, the concepts started coming together.
I had to think about the interface, application logic, data, database operations, and how everything connected. I had to make decisions about how to organise my code and figure out what to do when something wasn't working as expected.
I couldn't treat each feature as an isolated exercise because the features had to work together.
That was a different experience.

I also began to understand that building an application requires more than knowing which methods to use or how to write a particular function.

You have to think about the structure of the application.
You have to decide where responsibilities belong.
You have to understand how data moves between different parts of the system.

And when something breaks, you have to investigate instead of assuming you know the answer.

I didn't suddenly become an expert by building MarkDump. There are still plenty of things I need to learn, and I know there are better ways to approach some of the problems I've encountered.
But I now have practical experience to build on.

I've had to take concepts I've been learning and apply them to something bigger than an individual exercise.

For me, that has been one of the most valuable parts of the experience.

What's next for MarkDump?

There are still features to build, problems to solve, and decisions to make.

Authentication, payments, order management, and Drops remain on my list. I also want to continue improving the way the application is structured as I learn more.

But I'm glad I took on the project during my SIWES.

It gave me the opportunity to work on something substantial, challenge myself, and discover areas where I need to improve.

Most importantly, it showed me what happens when the things you learn individually have to work together in an actual application.
I'm still learning JavaScript. I'm still figuring out application architecture. And I'm still working towards becoming a better developer.

MarkDump is one step in that journey.
It isn't a story about building the perfect application on the first attempt.

It's a story about taking on something new, working through the challenges, and learning along the way.

And since this was my first time working on a project like this, I'm looking forward to seeing how much better I can make it.

For now, there's still work to do.

Back to the code. 😭

Yeah, here is a list of Technologies used

Frontend: HTML, CSS, vanilla JavaScript
Backend and database: Afribase-https://useafribase.app/
Live demo: https://deolawage.github.io/MarkDump/
Source code: https://github.com/Deolawage/MarkDump

Classes, Objects, Constructors, or Factory Functions — Which One Should I Use? 🤔

Deolawage — Mon, 28 Sep 2026 11:33:39 +0000

Hello, World! 👋

I've been learning JavaScript for a while now, and recently I've been spending more time with objects, constructors, classes, and factory functions.

At first, I thought I just needed to understand what each one does.

Now I understand them a little better...

And somehow, that has created another problem. 😂

When am I actually supposed to use each one?

From what I've learned so far:

Objects can hold data and behavior.
Constructors can be used to create multiple objects with similar properties and methods.
Classes provide another way of creating objects and are useful for things like inheritance.
Factory functions can create and return objects without using new.

Okay, I understand that.

But when I'm actually building something, how do I decide?

For example, let's say I need to create multiple objects with similar properties and methods.

I could use a class.

I could use a constructor function.

I could use a factory function.

So... which one do I pick? 😭

And then another question came to my mind.

Can I use more than one?

Suppose I'm working on a bigger project.

Could I have something like:

A class for one type of object
A factory function for another
Plain objects for some application data

Or should I generally try to stick to one approach?

I don't know if mixing them is perfectly normal or if I'm just creating unnecessary complexity.

So I'm asking experienced developers:

How do you decide?

Do you have a rule of thumb for choosing between classes, constructors, and factory functions?

And if you've used more than one approach in the same project, what made you choose each one?

I'm not looking for someone to tell me “just use X.”

I'm trying to understand the reasoning behind the choice.

Right now, I'm learning the syntax.

I want to start learning how developers actually make these decisions when building real projects.

Would love to hear your thoughts.

Thanks! 🙏

Let's See How Far I Can Go: A journal of the things I'm building, learning, exploring, and figuring out along the way.

Deolawage — Sat, 26 Sep 2026 11:42:34 +0000

Hello, World. I’m Starting to Share the Journey.

I've spent a lot of time learning things quietly.

Writing code.
Breaking code.
Starting projects.
Abandoning some.
Coming back to others.
Having ideas I thought were brilliant at 2 a.m. and questionable by morning. 😭

And for a long time, most of that stayed in my head.

I think it's time to change that.

So, hello, World.

This is the beginning of a journal.

Not a journal in the traditional sense, but a public record of things I'm building, learning, exploring, and thinking about.

Some of it will be about technology.

Some of it will be about building a business.

Some of it will be about writing.

Some of it will probably make absolutely no sense to anyone except me.

And that's okay.

I don't have everything figured out

That's probably the first thing worth saying.

I'm still learning.

I'm still making mistakes.

I'm still Googling things that I feel like I should already know.

I'm still staring at code wondering why something isn't working, only to discover that I forgot a semicolon, used the wrong variable, or spent two hours solving a problem I created myself.

That's part of the journey.

I recently finished The Odin Project Foundations, something that took me much longer than I originally expected.

I started, stopped, came back, struggled, learned, got confused, figured things out, and eventually finished.

Finishing it didn't suddenly make me a great developer.

It simply showed me that I could keep going.

And now there are many more things ahead.

JavaScript.

React.

Backend development.

Cloud.

Real projects.

Real users.

And eventually, real clients.

Building Deolawage

One of the things I'm currently exploring is turning Deolawage into something more than just a name I use online.

I want it to become a website-creation brand.

The idea is simple:

Build useful websites for real businesses.

I'm particularly interested in working with small businesses and eventually serving clients.

That means I have a lot to figure out.

What should I offer?

Who exactly should I serve?

How should I price my work?

How do I find clients?

How do I communicate with them?

How do I turn a website from something that looks nice into something that actually helps a business?

I don't have all the answers yet.

That's partly why I want to document it.

Why share all of this?

Because I've realised that learning doesn't only happen when you reach the finish line.

Sometimes the most interesting part is everything that happens before it.

The confusion.

The failed attempts.

The small breakthrough.

The project that finally works.

The idea that doesn't.

The lesson you didn't expect to learn.

I want to keep a record of those things.

Maybe someone else will find something useful in them.

Maybe someone will relate to the struggle.

Maybe, years from now, I'll look back at these posts and realise how much I've changed.

That alone makes documenting the journey worthwhile.

This is not a success story

Not yet, anyway.

I'm not writing this from the other side.

I'm writing it from the middle.

I'm still figuring things out.

I'm still building.

I'm still learning.

And honestly, I think that's where the interesting part is.

So this isn't:

“Look at everything I've achieved.”

It's more like:

“Come see what happens next.”

I'll share the projects I build.

The things I learn.

The mistakes I make.

The ideas I'm exploring.

The lessons I pick up along the way.

And occasionally, whatever random thought happens to escape this tiny brain of mine.

Hello, World.

I've spent enough time keeping ideas to myself.

It's time to put some of them out there.

This is the beginning.

Let's see what I can build.

I Finally Finished The Odin Project Foundations — 7 Months Later

Deolawage — Wed, 09 Sep 2026 21:23:39 +0000

I Finally Finished The Odin Project Foundations — 7 Months Later

On February 22, 2026, I started The Odin Project's Foundations path.

I didn't finish it in February.

I didn't even stay consistent for the first few weeks.

I started with excitement, went through the lessons for about a week or two, then stopped.

Life happened. Other things came up. My consistency disappeared.

But I wasn't completely done.

I came back in March.

And this time, I kept going.

Not perfectly.

Not every day.

Not without getting stuck.

But I kept moving.

And now, in September, I can finally say:

I finished The Odin Project Foundations.

It took much longer than I expected

When I started on February 22, I wasn't thinking about September.

I wasn't thinking:

“Let me see if I can finish this in seven months.”

I was just starting.

HTML.

CSS.

Git.

JavaScript.

The command line.

Developer tools.

And eventually, all the little concepts that start connecting together as you progress.

At some point, I realized this wasn't going to be a quick sprint.

It was going to take time.

And honestly, I'm glad it did.

I stopped

This is something I don't want to leave out.

I started the Foundations path and stopped after roughly a week or two.

For a while, I wasn't progressing.

And that's easy to feel ashamed about when you see people online posting:

“Day 47 of coding.”

“Finished this course in 30 days.”

“Built my first full-stack app in three weeks.”

Meanwhile, you're looking at the same lesson you've been looking at for days.

But I've learned something:

Someone else's pace doesn't determine yours.

I stopped.

Then I came back.

That's what mattered.

March came, and I continued

When I picked it up again in March, I didn't suddenly become a disciplined coding machine.

I still struggled.

There were lessons I had to reread.

There were assignments where I stared at the screen wondering what exactly I was supposed to do.

And there were concepts that only started making sense after I had actually struggled with them.

But something changed.

I started understanding that learning to code isn't about constantly feeling like you know what you're doing.

Sometimes learning looks like:

Read → get confused → try → fail → search → try again → understand a little → repeat.

And that's okay.

JavaScript especially humbled me

If you've followed my learning journey, you already know JavaScript has given me some interesting moments. 😭
For real, bro traumatized me.

Loops and arrays alone nearly broke me.

I spent weeks working through them and eventually started noticing something I didn't have at the beginning.

I could read an assignment and actually have an idea of where to start.

Not always.

But sometimes.

And those moments mattered.

Because they showed me that I wasn't just consuming tutorials anymore.

I was beginning to think through problems.

That's a completely different feeling.

Seven months later...

Now I'm at the end of the Foundations path.

And strangely, finishing doesn't feel like the huge ending I imagined when I started.

It feels more like reaching a checkpoint.

I've learned a lot.

I've also discovered how much I don't know.

And I think that's one of the most valuable things this journey has given me.

The more I learn about development, the bigger the world becomes.

There are frameworks.

Libraries.

Backend development.

Databases.

APIs.

Cloud.

System design.

Testing.

Security.

And a ridiculous number of things I haven't even discovered yet.

So no, I don't feel like a “finished developer.”

I feel like someone who has finally built a stronger foundation.

And that's enough.

I'm proud of this one

Not because I completed The Odin Project.

But because I came back.

I could have left it somewhere around February and never touched it again.

I didn't.

I continued in March.

I struggled through the months that followed.

And now, in September, I've finally reached the end of Foundations.

That's something I'm proud of.

Maybe the most important lesson wasn't even in the curriculum.

It was this:

You can pause without quitting.

Sometimes you need to step away.

Sometimes your pace changes.

Sometimes your motivation disappears.

But if the goal still matters to you, you can come back.

But I'm not done

Finishing Foundations isn't the finish line for me.

It's another starting point.

There are still many things I want to learn.

Many things I want to build.

Many bugs I want to fight.

Many projects that exist only as ideas in my head.

And ultimately, there is still a bigger dream I'm working toward.

I don't know exactly how long it will take.

I don't know how many times I'll have to stop, restart, get stuck, or change direction.

But I know I'm moving.

And that's what matters.

More steps ahead.

More things to learn.

More things to build.

More mistakes to make.

JavaScript Loops and Arrays Nearly Broke Me — The Odin Project

Deolawage — Thu, 13 Aug 2026 16:23:01 +0000

Four weeks of confusion, broken code, and slowly learning to see the solution before writing the code.

I'm currently working through The Odin Project, and recently I went through the JavaScript section covering **loops and arrays.

At first, I thought:

"Okay, I understand this."

I read through the lessons.

I followed the examples.

I understood what the code was doing.

Then I reached the assignments.

And that's when reality hit me.

I didn't actually understand it.

Reading Isn't the Same as Understanding

This was probably my biggest mistake.

I read through the material and felt like I understood the concepts because the examples made sense.

But when I was given an assignment and had to solve something myself, I just stared at the screen.

I knew what a loop was.

I knew what an array was.

But I didn't know how to use them to solve the problem in front of me.

It was like knowing the words of a language without knowing how to form a sentence.

That's when I realized:

I had been reading instead of learning.

So I Asked Claude for Help

At this point, I decided to get some help from Claude.

But I didn't want it to just hand me the answers.

I didn't want:

"Here's the solution. Copy this."

That wouldn't help me.

So instead, I used Claude to help me understand the **technical concepts behind the assignments.

Whenever I was confused, I'd explain where I was stuck.

Instead of giving me the entire solution, it would break down the concept and give me clues about what I should be thinking about.

Sometimes I'd get something like:

"Think about what you're trying to track while the loop runs."

Or:

"What should happen to each item in the array?"

Those little clues were often enough to get me moving.

And when they weren't...

Well, I went back and struggled some more.

The First Assignment Was Rough

I started the first assignment with almost no idea what I was doing.

I wrote some code.

It didn't work.

I changed something.

It still didn't work.

I broke the code.

Fixed something.

Broke something else.

At some point, I was probably just staring at the screen wondering why I had decided to learn programming.

But I kept going.

And something interesting started happening.

I Started Getting Better

The first few assignments felt like I was fighting the computer.

But as I progressed, things started becoming a little clearer.

I began understanding what the assignment was actually asking me to do.

I started breaking problems into smaller pieces.

Instead of immediately thinking:

"How do I write this code?"

I started asking:

"What exactly am I supposed to accomplish?"

Then:

"What data do I have?"

"What do I need to do with it?"

"Do I need to go through every item?"

"What do I need to keep track of?"

Those questions started changing everything.

Then Something Weird Happened

After working through enough assignments, I reached a point where I'd read an instruction and...

the concept would just come to me.

Not always.

I still got stuck.

But more often than before, I'd read the problem and think:

"Oh... I think I know what I need here."

Maybe it was a loop.

Maybe I needed to iterate through an array.

Maybe I needed to create another variable to keep track of something.

Maybe I needed to transform the data.

The important thing was that I wasn't just remembering some code I'd seen before.

I was beginning to recognize the type of problem.

And that felt different.

I Was Starting to Think in Code

This was probably the biggest change.

Before, I was looking at code and asking:

"What does this syntax mean?"

Now I was starting to look at a problem and ask:

"What logic would solve this?"

That's a completely different way of learning.

The syntax still matters, of course.

But eventually, you need to get past:

"What does for mean?"

and start thinking:

"I need to go through every item in this collection and do something with each one."

That's when programming starts becoming less about memorizing syntax and more about solving problems.

I Still Get Stuck

I don't want to make this sound like I suddenly became a JavaScript wizard after four weeks.

I didn't.

I still get stuck.

Sometimes I understand the problem but can't figure out the implementation.

Sometimes I have the right idea but write the wrong code.

Sometimes I completely misunderstand the problem.

And sometimes I spend way too much time on something that eventually turns out to be simple.

But there's one major difference now.

Being stuck doesn't feel as scary as it used to.

I know that if I keep breaking the problem down, looking at the concepts, experimenting, and trying again, I'll eventually get somewhere.

AI Helped Me, But It Didn't Do the Work For Me

I also learned something from using Claude during this process.

AI can be extremely useful when you're learning to code.

But there's a huge difference between using AI to learn and using AI to avoid learning.

If I had simply asked:

"Solve this assignment."

and pasted the answer into my project, I probably would have finished the assignment much faster.

But I would have learned much less.

Instead, I tried to use Claude more like a tutor.

Explain the concept.

Give me a clue.

Point me in the right direction.

Help me understand why something wasn't working.

Then let me struggle with the actual problem.

That struggle was important.

Because the moment I finally solved something myself, I understood it differently.

Four Weeks Later

After spending roughly four weeks working through loops and arrays, I can finally say that they make a lot more sense to me.

Not because I've memorized everything.

Not because I can solve every problem instantly.

But because I'm starting to recognize patterns.

I can read an assignment and sometimes already have an idea of the concept I need before I even start writing code.

And honestly, that feeling is amazing.

It's a small thing.

But when you've spent weeks being confused, that little moment of:

"Wait... I know what to do."

feels huge.

But I'm Not Done

I'm still working through The Odin Project.

I'm still learning JavaScript.

I'm still getting stuck.

I'm still breaking things.

I'm still asking questions.

And I still have a long way to go.

Four weeks of loops and arrays didn't make me a great programmer.

But it taught me something more important:

Understanding takes time.

Sometimes you have to read something twice.

Sometimes you have to fail at an assignment.

Sometimes you have to break your code.

Sometimes you need someone—or something—to give you a clue.

And sometimes you just need to keep going until the pieces finally start connecting.

So yeah...

JavaScript loops and arrays nearly broke me.

But they didn't.

I'm still here.

Still learning.

Still building.

Still growing.

And I've got a long way to go.

Let's see where this journey takes me. 🚀

[Boost]

Deolawage — Tue, 11 Aug 2026 10:07:19 +0000

Deolawage

Aug 11

Three Years Later, I Finally Submitted My Frontend Mentor Challenge

#frontmentor #frontendchallenge #beginners

3 min read

Three Years Later, I Finally Submitted My Frontend Mentor Challenge

Deolawage — Tue, 11 Aug 2026 10:04:20 +0000

I Finally Submitted a Frontend Mentor Challenge I Started in 2023

Three years, one old project, one tablet, and a very different version of me.

In 2023, I did something that probably felt very small at the time.

I started a Frontend Mentor challenge.

I was still very early in my journey with frontend development. I was learning, experimenting, breaking things, fixing them, and trying to understand how websites were actually built.

And here's the funny part:

I didn't even have my own laptop.

I built the project using my dad's tablet.

Yes, a tablet.

I was determined enough to make it work.

I remember opening my code, working through the design, trying to make the page look like the challenge, and learning things along the way.

But I didn't finish it.

Or rather...

I didn't submit it.

Life moved on.

I continued learning frontend development. I started working on other projects. I learned more HTML and CSS. Eventually I moved into JavaScript and started exploring backend development too.

That old challenge just became one of those unfinished things sitting somewhere in my past.

Fast forward to 2026

During my SIWES, I was given an assignment at my training center.

The assignment was related to Frontend Mentor.

When I saw it, I immediately remembered the old challenge.

That project from 2023.

The one I had built on my dad's tablet.

The one I never submitted.

And I thought:

"Why don't I finally finish it?"

So I went back to it.

Coming back to old code is weird

One of the strangest experiences as a developer is looking at code you wrote years ago.

You see things you used to think were difficult.

You see decisions you would make differently now.

You notice mistakes that you didn't even realize were mistakes.

And sometimes you just stare at something and think:

"Why did I write it like this?"

But that's actually one of the best ways to see your growth.

The code wasn't necessarily terrible.

I had just changed.

The developer who started that project in 2023 wasn't the same developer who returned to it in 2026.

The project became more than a challenge

When I finally worked on it again, I wasn't just trying to complete an old Frontend Mentor assignment.

I was comparing two versions of myself.

2023 me
Learning the basics
Figuring out CSS
Working with limited resources
Building on a tablet
Trying to understand how everything worked
2026 me
More comfortable with HTML and CSS
Learning JavaScript
Working with Git and GitHub
Building full-stack projects
Thinking about responsive design differently
Understanding code structure better
More comfortable debugging problems

And the funny thing is...

The project hadn't changed.

I had.

I finally submitted it

After all those years, I finally submitted the challenge.

Not in 2023.

Not in 2024.

Not in 2025.

2026.

Three years after I started it.

And honestly, I'm glad I didn't delete it.

Because if I had, I wouldn't have had the opportunity to see how much I had grown.

Finish the old projects sometimes

There's a lesson I'm taking from this.

As developers, we're always looking forward.

The next tutorial.

The next framework.

The next project.

The next challenge.

The next thing we need to learn.

But sometimes it's worth looking backward.

Open an old project.

Read your old code.

Run it again.

See what you understand now that you didn't understand then.

You might be surprised.

Not because the old project is amazing.

But because you're no longer the person who built it.

From a tablet to where I am now

The part that makes me smile the most is remembering that I built that first version using my dad's tablet.

At the time, I didn't have all the resources I have now.

But I had curiosity.

And I had the willingness to try.

Three years later, I'm still here.

Still learning.

Still building.

Still breaking things.

Still fixing things.

Still trying to become a better developer.

And that old Frontend Mentor challenge?

It finally has a submission.

Better late than never.

What about you?

Do you have an old project sitting somewhere that you never finished?

Maybe you should open it again.

You might not just finish the project.

You might discover how much you've grown.