Independent development of
Web systems

I work from analyzing and correcting legacy code to ideas still on paper and projects that need to evolve.
I understand the problem before deciding on the solution, focusing on clarity, performance and not complicating what can be simple.

Technology

You are not alone.

If you have already tried to turn an idea into reality, run a project with other people or simply make something work as agreed, and felt that everything became more complicated than necessary… that is not a lack of vision or ability.

Most of the time, the problem lies in accumulated poor decisions, bad shortcuts and solutions pushed forward without truly understanding what needed to be solved.


I work with my own resources, without ready-made formulas, without pushing tools just because they are trending.
My focus is to understand the problem before any decision and build something that makes sense today and keeps working tomorrow.


If you are looking for someone who treats your project with seriousness, clarity and respect for the process, then let’s talk.

The problem is not you

Decisions come before any solution

Understand before building

I do not start a project by choosing tools, languages or frameworks.

I start with the problem. With the context. With what truly needs to be solved and, above all, with what does not need to exist.

I use PHP deeply, JavaScript when it makes sense, Node when necessary, and even Python when the scenario requires it. It is not about personal preference, but about efficiency and clarity.

Frameworks? I avoid them as much as possible. Not out of stubbornness, but because excessive abstraction charges high interest later. I use classes, libraries and my own structures when they actually help.

Complexity only enters when it is unavoidable.

Many failures happen because technical decisions are made too early… and later no one wants to go back.

When the foundation is clear, development flows. When it is not, any solution turns into a patch.

Clarity prevents rework

I prefer to move forward safely rather than rushing to look productive.
That means doing less at the beginning in order to get more right along the way.

Clear code, well-explained decisions and simple solutions are not shortcuts… they are what allow a project to evolve without breaking at every change.

When the foundation is well thought out, adjustments stop being traumatic and become a natural part of the process.
This reduces unnecessary fixes, makes maintenance easier and provides predictability for whoever works on the project in the future… including myself.

It is not about writing more code, but about writing the right code, at the right time, with the least possible noise.

What I solve in practice

Projects and evolution

Not every job is about creating something from scratch. Often it is about continuing, correcting, redirecting or structuring what already exists.

Many times the real work lies in understanding what already exists, correcting the course and creating foundations that allow real evolution.

  • Existing systems that need to be corrected or reorganized
  • Legacy code that “no one” wants to touch anymore
  • Projects that started poorly but still have a solution
  • Ideas that need to leave paper with proper structure
  • Automations to reduce manual tasks and repetitive processes
  • Security care: data, forms, files and integrations
  • Technical maintenance: fixes, adjustments and ongoing stability

Websites, fixes and real maintenance

Most websites break due to poor decisions: excessive dependencies, fragile solutions, lack of updates and missing technical maintenance.

Plugin-heavy platforms and site builders promise ease, but deliver structures that are hard to fix when something goes wrong. The result is a false sense of simplicity… until the first real problem appears.

webship works differently:

  • Websites built from scratch with their own structure
  • Fixes and adjustments on existing sites (including WordPress)
  • Code organization and performance optimization
  • Continuous technical maintenance, without improvisation

Automations and Security

In practice, I solve things that usually become headaches:

Automations: Manual processes that look like “magic” when automated, but were actually just waiting for someone to look at them calmly.

Integrations, internal flows and repetitive tasks that “no one” wants to keep doing.

Security: Not as paranoia, but as an obligation. A system without security is like leaving a brand-new car unlocked with the key inside.
It does not matter if the site is small or large — someone will always try to break in.

I learned this in practice while developing Opus Core, where security is not an extra: it is part of the foundation.

How I work (and why it matters)

I work independently because it gives me control over decisions, quality and time.
I do not rely on bloated structures, misaligned teams or processes that exist only to justify costs.

This allows me to adapt the project to the reality of the person on the other side… even when the budget is limited or the idea is still being shaped.

The work starts small when needed, evolves when it makes sense and changes when reality changes.
No rigid contracts, no unrealistic promises and no hiding what is being done.

Money is part of the process, not its center.
The focus is to build something that works, is understandable and can evolve over time.

So… who is webship, really?

My name is Wellington Pragidi, an independent developer.
webship is a registered brand, not a bloated agency, not a website factory, and not a company filled with layers and bureaucracy.
That means less noise, no empty promises and direct responsibility for what is delivered.

When something works, it was me. When something breaks, it was also me.

Projects

Systems and solutions born from real problems

Opus Core

A system under continuous development started over five years ago.

Created to be lightweight, transparent and evolutive, without unnecessary inheritance.
Opus does not hide code, does not depend on trends and does not grow by accumulation. It grows by necessity.

It was not created to compete with WordPress or please the masses. It was created to solve real problems without carrying the weight of old decisions.

Internally open code, clear structure, a panel that does not grow without need and no blind dependency on asynchronous JavaScript when it does not solve a real problem.

Packit

Packit UI is a set of tools for visual and structural interfaces, designed to allow using only what the project actually needs.

Unlike most solutions of this kind, it does not force the adoption of all modules nor tie the project to rigid models or forced rewrites.

To this day, no project has needed everything it offers… and that is not a limitation, it is criteria.

It serves as a base and solves the trivial so the focus can stay on the details that truly matter.

EMA: Management and Query Software for INPI RPI Trademark Analysis

A project developed for automated PDF processing, using OCR Tesseract and Ghostscript integrated directly, without the need for Composer — meaning no unnecessary dependencies.

The challenge was to separate processes based on visual markers and remove specific elements from files.
Everything worked and was delivered ahead of schedule. Part of this was only possible because I reused existing classes and helpers from Opus, which does not hide behind abstractions, saving real development time.

In the first phase alone, the process table exceeded 13 million records.