4 min read
When to improve a WordPress site instead of rebuilding it
A practical way to decide whether an existing WordPress site is worth fixing or has reached its limit.
Read noteSenior full-stack developer
I build and improve websites and web applications with PHP, Laravel, Next.js, and WordPress.
Most of my work is e-commerce performance, Laravel APIs, and WordPress or headless CMS builds.
Working in web development since 2016 · PHP, Laravel, WordPress, WooCommerce, Next.js, TypeScript
Services
What I can help with
I take on work around PHP, WordPress, Next.js, and the performance problems that tend to appear as a product grows.
Headless WordPress + Next.js
Keep WordPress for publishing and use Next.js for a faster public site or storefront when the existing theme has become a limitation.
Performance & Core Web Vitals
I investigate LCP, CLS, and TTFB, then work through images, bundles, caching, and server responses to find the real bottleneck.
Laravel APIs & backends
PHP APIs, integrations, and internal tools for products that need more than a marketing site or a page builder.
Technical consulting
A technical review, migration estimate, or second opinion before you commit to a larger build.
Fit
When I can be useful
A few examples of work that is usually a good match.
Good fit
- Your WordPress site is slow, difficult to update, or has collected too many plugins and one-off fixes.
- You need a Laravel API, integration, or internal tool alongside an existing product.
- You have a design in Figma and need a responsive, accessible implementation.
- You need to decide whether an existing site should be improved, rebuilt, or separated into a CMS and frontend.
Probably not a fit
- A logo, brand identity, or a template-only brochure site.
- A large team-management role with little hands-on development.
- A fixed quote before there is enough information to understand the work.
Selected work
Examples of the work I take on
These examples are anonymized, but the problems and approach are representative of recent work.
Large WooCommerce store
Situation: Product and category pages loaded too much theme code, especially on mobile. The team was concerned about the effect on paid traffic.
What I did: I removed legacy template JavaScript where possible, optimised images and fonts, and reduced the critical path on product and category pages.
What changed:
- LCP and interaction delay improved after the performance work.
- The existing WooCommerce catalogue and checkout workflows stayed in place.
WordPress publishing site under load
Situation: The public site and the WordPress admin competed for the same PHP workers whenever traffic increased.
What I did: I separated publishing from delivery: WordPress remained the editorial CMS, while Next.js served readers with cache rules that protected the origin.
What changed:
- Editors had a more reliable admin experience while readers used a faster public site.
- The frontend and content API could be deployed and rolled back independently.
Laravel APIs for React dashboards
Situation: A small number of busy endpoints and N+1 queries caused slowdowns at peak times.
What I did: I profiled the queries, fixed eager loading where it mattered, and added caching only where the data could safely be less than real-time.
What changed:
- Response times on the busiest calls became stable enough for the team to monitor.
- The largest frontend bundles were reduced on the affected screens.
Discuss a similar project
Or use the form with a short brief.
Working together
How a project usually starts
The process is straightforward: understand the work, build it carefully, and make the next step clear.
- 01
Understand the problem
I look at the goal, the existing system, and what is getting in the way. Then we agree what is worth doing first.
- 02
Build in small steps
I keep work visible and reviewable. Coding agents help with research and implementation; I make the technical decisions and review the result.
- 03
Leave things in good shape
You get the relevant notes, deployment details, and code that your team can continue to work with.
Stack
Tools I use regularly
These are the tools I use most often. I choose the approach based on the project rather than forcing every job into the same stack.
- React
- Next.js
- TypeScript
- Laravel
- PHP
- Headless WordPress
- WooCommerce
- GraphQL
- REST APIs
- Docker
- Tailwind CSS
Notes
Things I write down while working
Practical notes on WordPress, migrations, performance, and choosing a technical approach.
4 min read
When headless WordPress is worth the extra complexity
Headless WordPress can solve real delivery and performance problems, but it is not the default answer for every site.
Read note5 min read
What I check before estimating a website migration
A useful migration estimate starts with the existing site, content, integrations, and the people who will run it after launch.
Read noteAbout
Radosław Golan
I have worked in web development since 2016. I started with frontend and WordPress work, then moved into full-stack projects, PHP, Laravel, and performance work.
These days I work mostly on e-commerce performance, WordPress and headless CMS projects, and Laravel APIs.
I take on freelance projects with a defined scope, and I am also open to senior full-time or long-term B2B roles.
I use coding agents for research, implementation, and refactors. I still make the technical decisions, review changes, and test the work.
Want to discuss a project?
A short call is usually the quickest way to work out whether I can help and what the next step should be.
Contact
Tell me about your project
Book a call if you would rather talk. Use the form if you want to send a brief first.
Response time
I usually reply within one business day. If you have a deadline, include it in your message.
What happens next
- ✓I read the brief and reply directly.
- ✓If the project is a fit, we arrange a call or discuss the scope by email.
- ✓I will tell you if I need more information before I can estimate the work.
- ✓If I am not the right fit, I will say so.