DEV Community: Marceli Pawliński

Curiosity Over Comfort

Marceli Pawliński — Tue, 06 Oct 2026 21:47:16 +0000

I’m More Interested in Why Things Break Than Why They Work

I don’t think I became interested in technology because I wanted to build apps.

I think I became interested because I wanted to understand things.

There’s a difference.

When something works exactly as expected, there usually isn’t much mystery left.

You press a button, something happens, and you move on.

But when something breaks, everything becomes more interesting.

Why did it fail?

Was the assumption wrong?

Was the system badly designed?

Did someone trust something they shouldn’t have?

Was the problem in the interface, the network, the database, the user, or somewhere deeper?

That way of thinking has probably shaped most of what I build.

I Like the Parts People Usually Ignore

A lot of software is designed to hide complexity.

That is normally a good thing.

Most people do not care how a request is routed, how authentication is validated, how a database transaction is handled or how an AI model receives context.

They just want the thing to work.

I tend to get interested in the hidden part.

I want to know what happens between clicking a button and getting a result.

I want to know what happens when that process is interrupted.

I want to know what assumptions the developer made and what happens if those assumptions are wrong.

That is part of why cybersecurity became interesting to me.

Security often lives in the gap between what a system appears to do and what it actually allows.

Building Things Is Mostly Discovering What You Don’t Know

One of the strangest things about programming is that the more I learn, the less I feel like I know.

When I started building websites, a website felt fairly simple.

Frontend.

Backend.

Database.

Done.

Then you start learning about authentication, caching, queues, rate limits, browser behaviour, network failures, accessibility, search engines, deployment, monitoring, observability and security.

Suddenly a “simple website” doesn’t seem simple anymore.

The same thing happened when I started experimenting with AI.

At first, the interesting part was the model.

Which one is smarter?

Which one is faster?

Which one can run locally?

Eventually the model became only one small part of the problem.

A model can be extremely intelligent and still be useless if the system around it is badly designed.

It needs context.

It needs tools.

It needs boundaries.

It needs a way to fail safely.

It needs to know what it is allowed to do.

That is where things get much more interesting.

I Don’t Really Separate Learning From Building

I’ve never been very good at learning something just because I’m supposed to know it.

I understand things much better when I need them.

If I need a database for a project, I learn about databases.

If authentication breaks, I learn more about authentication.

If a website is slow, I start learning about performance.

If a deployment fails, I learn what the infrastructure is actually doing.

That process is sometimes inefficient.

I’ll probably make mistakes that someone with more experience would avoid immediately.

But those mistakes normally stick with me.

There is a big difference between reading that something is a bad idea and spending six hours discovering why it is a bad idea.

Zenith Is Really an Excuse to Learn

My main project, Zenith, is technically a website monitoring and improvement platform.

But for me, it is also an excuse to keep exploring problems.

Security.

Performance.

Accessibility.

SEO.

Infrastructure.

Automation.

AI.

Databases.

Product design.

They all meet in one project.

I could probably make Zenith much smaller and easier to build.

That would also make it less interesting.

I like projects that slowly force me outside what I already know.

Open Source Changed How I See Programming

Building your own projects gives you complete control.

That is both useful and dangerous.

If something is badly designed, you can always rewrite everything around it.

Open source removes that freedom.

When you contribute to someone else’s project, the question is not:

“How would I build this?”

It is:

“Why did they build it this way?”

You have to understand before changing.

You have to work with existing conventions.

You have to think about the people who already depend on the code.

I like that.

It makes programming feel less like writing instructions for a computer and more like working inside a system built by people.

I’m Still Figuring Out What I Want to Become

I’m interested in computer science, cybersecurity, AI and systems engineering.

That is a fairly wide answer.

For now, I’m okay with that.

I don’t think I need to decide exactly what I want to specialise in yet.

I would rather keep following the problems that make me curious.

The common theme seems to be systems.

Not just how to build them, but how they behave when something unexpected happens.

That could mean security.

It could mean infrastructure.

It could mean AI systems.

It could end up being something I haven’t discovered yet.

The Goal Isn’t to Know Everything

I used to think being good at technology meant knowing the answer.

Now I think it is more about knowing what to do when you don’t.

Can you break a problem apart?

Can you find the part you don’t understand?

Can you test your assumptions?

Can you admit when an idea was wrong?

Can you keep going when the first solution doesn’t work?

That matters more to me now than memorising every framework or programming language.

Technology changes too quickly for that anyway.

There will always be another tool.

Another language.

Another model.

Another platform.

The useful part is learning how to learn.

And preferably building something interesting while doing it.

I’m Marceli Pawliński.

I build software, experiment with AI, contribute to open source and spend an unreasonable amount of time trying to understand why things behave the way they do.

Most of the time, the best place to start is when something breaks.

About Me: Building, Breaking and Learning Through Software

Marceli Pawliński — Tue, 06 Oct 2026 21:33:56 +0000

About Me: Building, Breaking and Learning Through Software

Hi, I’m Marceli Pawliński.

I’m a student from Scotland interested in computer science, cybersecurity, artificial intelligence and software engineering.

Most of what I know has come from building things, breaking them, fixing them, and then realising there was probably a better way to build them in the first place.

How I Got Into Computing

Computers have been part of my life for as long as I can remember.

Over time, that turned from simply using technology into wanting to understand what was happening underneath it.

I started experimenting with programming, websites, servers, local AI models and cybersecurity.

The more I learned, the more interested I became in what happens when systems stop behaving the way they are supposed to.

That is probably the part of computing I enjoy most.

A system working correctly is useful.

A system failing in an unexpected way is interesting.

What I Build

My main project at the moment is Zenith.

Zenith is a platform designed around one idea:

Monitor, improve and grow your website.

It brings together website monitoring, security checks, performance analysis, accessibility, SEO and growth opportunities.

Building Zenith has pushed me into areas I probably would not have explored otherwise, including:

Cloudflare Workers
databases
authentication
queues
APIs
scheduled jobs
browser automation
security headers
rate limiting
website auditing
AI-assisted analysis

It has also taught me that building a product is very different from building a feature.

A feature can work perfectly on its own and still make no sense inside the wider system.

Open Source

I also spend a lot of time on GitHub.

My GitHub is a mixture of personal projects, experiments and contributions to other repositories.

One project I’ve been working on is browser-harness, where I’ve been exploring how AI systems can interact more reliably with websites and browser interfaces.

I also enjoy contributing to existing open-source projects.

Working on someone else’s code is very different from starting from an empty file.

You have to understand why something was built a certain way before deciding how to change it.

Sometimes a useful contribution is only a tiny fix.

That is still valuable.

AI and Local Models

I started properly experimenting with large language models around 2023.

Since then I’ve worked with tools and models including:

Ollama
llama.cpp
LM Studio
Qwen
Llama
DeepSeek

At first I was mainly interested in the models themselves.

Eventually I became more interested in everything around them.

How does an AI use tools?

How do you give it permissions safely?

How does it interact with browsers?

How do you handle memory?

How do you stop an automated system from doing something it shouldn’t?

How do you make it reliable when the real world is unpredictable?

Those questions are much more interesting to me than simply asking which model has the highest benchmark score.

Cybersecurity

Cybersecurity is another major interest of mine.

I especially like looking at the difference between how secure something appears and how secure it actually is.

A polished login page does not necessarily mean the backend is secure.

A website having HTTPS does not mean everything behind it is configured correctly.

A security feature existing does not mean it has been implemented properly.

That way of thinking has changed how I approach software development in general.

Instead of only asking:

“Does this work?”

I also try to ask:

“How could this fail?”

Learning Outside School

I’m currently studying subjects including Maths and Computer Science, but a lot of my technical learning happens outside the classroom.

I experiment with my own infrastructure, contribute to GitHub projects, build websites, run local AI models and work through technical certifications.

I’ve also completed learning in areas including AI literacy and introductory cybersecurity.

I like structured learning, but I learn best when I can actually use something.

Reading about databases is useful.

Designing one badly, discovering the problems and then fixing it teaches you something different.

What I Want to Do

Long term, I want to work somewhere around the intersection of:

AI, cybersecurity, systems and computer science.

I’m still figuring out exactly what that looks like.

That is partly why I build so many different things.

Every project gives me a slightly better idea of what I enjoy, what I’m good at, and what I still need to understand.

Right now, I’m focused on improving Zenith, contributing more to open source and continuing to build projects that force me to learn things I don’t already know.

If something breaks along the way, that normally makes it more interesting.

Find me

GitHub: github.com/marceli1404

Website: marcelipawlinski.co.uk

Zenith: zenith.me.uk

I’ll be writing here about software development, cybersecurity, AI, open source, website infrastructure and whatever I happen to be experimenting with next.

Building Zenith: What I’ve Learned From Turning Side Projects Into Real Software

Marceli Pawliński — Tue, 06 Oct 2026 21:30:18 +0000

Building Zenith: What I’ve Learned From Turning Side Projects Into Real Software

I’ve built a lot of small projects over the years.

Some lasted a few hours. Some turned into GitHub repositories I still work on. Others eventually became part of something much bigger.

Zenith is probably the best example of that.

What is Zenith?

Zenith started from a fairly simple idea:

What if checking the health of a website didn’t require five different tools?

A website can be online and still have plenty wrong with it.

It might have:

weak security headers
accessibility problems
poor performance
broken redirects
missing SEO metadata
bad configuration
opportunities for growth that nobody notices

Zenith is my attempt at bringing those things together.

The goal is simple:

Monitor, improve and grow your website.

Rather than treating security, performance, SEO and accessibility as completely separate problems, I wanted to build something that looks at a website as one system.

That idea has changed quite a bit while I’ve been developing it.

And that has probably taught me more than the original idea ever did.

Building Things Changes How You Think

When I first started programming, getting something to work felt like the main objective.

If the page loaded, the API responded and the button did what it was supposed to do, that was a success.

I don’t really think that way anymore.

Now I usually start asking questions like:

Why does this work?

What happens when it doesn’t?

What happens if someone sends a request the interface never expected?

What happens when ten thousand requests arrive instead of ten?

That shift has made security and systems engineering much more interesting to me.

A login page can look completely secure from the browser while the backend behind it has serious problems.

A security header can exist while being configured in a way that makes it almost useless.

A website can score well in one audit while still giving users a terrible experience.

The interesting part is normally somewhere underneath the surface.

The Stack Behind Zenith

A lot of Zenith has been built around Cloudflare infrastructure.

I’ve experimented with things including:

Cloudflare Workers
D1
R2
Queues
scheduled jobs
rate limiting
authentication
bot protection
browser-based website analysis

One thing I like about this architecture is that it forces me to think about software differently.

Instead of having one large server doing everything, you start thinking about individual services, boundaries, failures and communication between components.

That introduces new problems.

But those problems are interesting.

What happens when a scan fails halfway through?

What gets retried?

What should be stored?

How much should be trusted?

What happens if one part of the system becomes unavailable?

Those are the kinds of questions I want to get better at answering.

Open Source Has Been Just as Important

A lot of what I’ve learned has also come from GitHub.

My profile contains a mixture of personal experiments, website tooling and contributions to other projects.

One project I’ve been experimenting with is browser-harness, which explores ways of making browser interaction easier for AI systems and automated agents.

I’m particularly interested in the gap between:

“An AI model understands what it should do.”

and

“The AI model can reliably interact with a real application and actually do it.”

Real websites are messy.

Forms behave differently.

Interfaces change.

Authentication exists.

Errors happen.

Pages contain information intended for humans rather than machines.

Making AI systems interact reliably with that environment is a surprisingly interesting engineering problem.

I’ve also spent time looking through existing open-source projects, fixing smaller issues and submitting contributions.

Those smaller changes are useful because they force you to work inside someone else’s decisions.

You can’t redesign everything.

You have to understand the project first.

Sometimes the best contribution is only a few lines of code.

AI Got Me Interested in Systems, Not Just AI

I first started seriously experimenting with large language models around 2023.

Since then I’ve tried different local models, inference tools and hardware setups.

I’ve used things like:

llama.cpp
Ollama
LM Studio
Qwen
Llama models
DeepSeek models
local GPU inference

At first, most of my attention was on the models themselves.

How large are they?

How much VRAM do they need?

How quickly can they generate tokens?

How good are they at coding?

Eventually I became more interested in everything surrounding the model.

Routing.

Tool use.

Memory.

Security.

Permissions.

Browser interaction.

Infrastructure.

APIs.

Failure handling.

A capable model by itself isn’t necessarily a capable system.

The engineering around it matters just as much.

I Still Build Things That Fail

A lot of my projects don't work perfectly the first time.

Sometimes the architecture is wrong.

Sometimes I massively overcomplicate something.

Sometimes I build a feature and later realise it shouldn't exist.

Sometimes I rewrite something that technically worked because I finally understand why the first version was bad.

I think that is one of the best parts of building your own projects.

There’s nowhere to hide.

If your database design is terrible, eventually you have to deal with it.

If your authentication flow is badly designed, you eventually discover why that matters.

If your interface is confusing, real users will find things you thought were obvious completely incomprehensible.

Every failure exposes something you didn’t understand before.

What I’m Working Toward

I’m particularly interested in the overlap between:

computer science, cybersecurity, artificial intelligence and distributed systems.

Zenith happens to touch nearly all of those areas.

There’s website analysis.

There’s infrastructure.

There’s security.

There’s automation.

There’s data.

There’s AI.

And most importantly, there are plenty of problems I still don’t know how to solve properly.

That’s probably why I keep working on it.

I don't just want to know how to make software work.

I want to understand why it works, where it breaks, and how to build it better the next time.

You can follow my projects on GitHub:

github.com/marceli1404

And Zenith is available at:

https://zenith.me.uk

I’ll be writing more about the architecture behind Zenith, security mistakes I’ve found while building web applications, local AI experiments, and the things I learn from contributing to open-source projects.

If you work on similar things, I’d love to hear what you’re building.