Online store development and optimization. Foundations, not plugins.
I develop and optimize live online stores - most often WooCommerce, but I also work on stores on other engines and custom builds. Three areas: I speed up the slow ones (measuring the result in Core Web Vitals before and after), I repair failures when the store is down, and I extend selling with B2B features. I go into the code, the cache and the database instead of gluing on another plugin. 8 years in production, a fixed bid in writing.
One page, three problems, one pair of hands.
Speeding up
A slow store loses carts on mobile and overpays for advertising. I go into the code, the cache, the database and the images - and I measure the result in Core Web Vitals before and after, not by eye.
Emergency repair
The store is down: white screen, checkout refusing payments, traces of a break-in, a conflict after an update. I go into the logs, find the cause and fix it - without guessing.
Adding B2B features
WooCommerce can be extended for business selling: price lists per customer group, prices visible only after login, minimum order quantities, credit limits. I extend the store you already have instead of standing a new one next to it.
Why is a WooCommerce store so slow?
Before you buy yet another speed-up plugin, check what really chokes Woo stores. WooCommerce optimization starts with a diagnosis, not with piling on more add-ons - and in those diagnoses the same bottlenecks come back almost every time:
Slow TTFB and cache without a plan
On cheap hosting the store waits over a second before the server even answers. And simply "turning cache on" is not enough in WooCommerce - the cart, the checkout and My Account have to be excluded from it, otherwise customers see somebody else's cart. That is why many stores keep the cache off entirely - and crawl.
Cart fragments on every subpage
The mechanism that refreshes the mini-cart calls the server on every subpage - including the blog, where nobody buys anything. It can add hundreds of milliseconds to every visit. It can be loaded conditionally, only where it is actually needed.
A bloated database
WooCommerce keeps temporary data (transients) and background jobs (Action Scheduler) in the database. When nobody cleans that up, the tables swell to hundreds of thousands of rows and the store slows down on its own, even though nothing in it has changed.
A heavy theme and too many plugins
A universal do-everything theme and a few dozen active plugins add their scripts, styles and queries to every subpage - even where they do nothing at all. The store loses Core Web Vitals before it even starts.
Images that were never resized
A 4000 px product photo displayed in a 300 px tile is the single most common LCP killer. Conversion to WebP/AVIF, correct dimensions and lazy loading can cut the weight of the heaviest element on the page by an order of magnitude.
What I do about it: page cache with exceptions for the cart and the checkout, Redis Object Cache and OPcache, a light front end (WebP/AVIF, lazy loading, conditional loading of plugin scripts), order in the database (transients, Action Scheduler, HPOS). The simplest test of whether your store is too slow: PageSpeed Insights on mobile - if LCP goes over 2.5 s, you are losing carts and overpaying for advertising.
Store down? Diagnosis first, repair second.
Your report comes straight to me and I pick it up immediately. WooCommerce repair starts here with the logs and the code: I establish the real cause and remove it, instead of smothering the symptom with another plugin. The most common reports:
White screen / critical error
A fatal error after a theme or plugin update. Often even the admin panel is down - you have to go in over FTP or straight into the database.
Checkout and payments are broken
Orders are not saved, the payment comes back with an error, or the customer does not see the Buy button at all. The most expensive failure - it hits revenue directly.
The store has been hacked
Foreign scripts, strange redirects, a warning in Google or an email from the host about malicious code. It has to be cleaned, the way in has to be closed and everything else has to be checked for damage.
A conflict after an update
An update of the WordPress core, WooCommerce or a plugin breaks something that used to work. The theme falls apart, a feature disappears, the store starts throwing errors.
The store falls over under traffic
Errors 500 or 504 at the worst possible moment - during a campaign or a sale. The server, the database or the queries cannot keep up with the traffic.
The process is always the same: diagnosis in the logs and the database, a backup before every intervention, the repair with a checkout and payment test, and finally protection so the same failure does not come back. If you want to sleep well permanently, after the repair I propose ongoing support with monitoring.
B2B selling added to the store you already run.
WooCommerce out of the box means one price list for everybody and payment upfront. Business selling needs four extra layers - I build them into your store, without standing up a platform from scratch:
Customer roles and group price lists
Prices depend on the assigned role or group: wholesaler, distributor, retail customer. The same store, a different range for every segment - without maintaining two separate stores.
Prices visible after login
Until the customer logs in they see neither prices nor the Add to cart button - only a form requesting access. Standard in B2B, so that your price list does not sit openly in Google for the competition.
Minimum order quantities (MOQ)
Orders from a set number of units or a full bulk pack - enforced at product or category level, impossible to get around in the cart.
Credit limits and deferred payment
Regular customers buy on an invoice with a payment term and an assigned credit limit, instead of paying upfront on every order the way plain Woo works.
Honestly about the proof: B2B features on WooCommerce are a competence built on 30+ Woo deployments since 2018 and on backend work at the scale of iGaming operators - financial modules and panels with high security requirements, done under NDA. I show that as background, not as a ready catalogue of cases - with no invented projects.
Before you get in touch - check for yourself.
Three pieces that let you work out where you stand on your own:
A real rebuild, real numbers.
Złota Faza - performance pushed from 38 to 100, Speed Index from 4.5 s down to 0.3 s. It is a company website rather than a store, but the mechanics were the same ones I work with in stores: heavy images, theme dead weight and a front end choking Core Web Vitals. Most rescue interventions go under NDA - the client wants quiet, not publicity.
"Krystian talked little and did a lot. He quoted, gave a deadline, delivered. The site is up, Google sees it, customers come in." Michał Wacławik · Złota Faza · Electrical Installations · translated from Polish
Before you write.
The quote is individual and in writing - no price list starting "from X PLN". I match the scope to the problem: a single plugin conflict looks nothing like cleaning up a hacked database. Speeding up an existing store is usually a fraction of the cost of building a new one, because I do not touch the whole structure, only the bottlenecks.
The simplest way: PageSpeed Insights on mobile - if LCP goes over 2.5 s and the score is in the red, you are losing carts and paying more for advertising. I run the diagnosis with a waterfall and Query Monitor, so I find the real bottleneck instead of a symptom.
With the diagnosis: I check the server error log, the WordPress and WooCommerce logs, the history of recent changes (updates, new plugins) and the database. In most cases the cause is visible before I fix anything - I do not guess by trial and error. I take a backup before every intervention.
Usually not - I work on a staging copy or fix the fault without closing the store to customers. A short maintenance window only happens in more serious cases (cleaning up after a break-in, repairing the database) and I always tell you upfront before I do it.
Yes - that is the most common scenario. We do not build a new platform, we extend the existing store with customer roles, group price lists, hidden prices, MOQ and credit limits. Products, orders and customers stay where they are, and retail and business customers buy in the same store.
A store slows down again over time: updates, new plugins, a growing database. The price includes 30 days of care after launch, and for the longer run there is ongoing support with monitoring that watches performance before it turns red again.
Store slowing down or falling apart?
Describe the project in a few sentences - I come back personally with the scope, a fixed bid and a deadline.