Work: systems that replaced manual work

Events · Full platform

The whole festival on one platform: website, sales, marketing and organiser data

Before: the whole festival was organised in spreadsheets that were duplicated and hard to follow, information was scattered, and the project manager's time went into coordination. After: organising is largely automated, and people's effort goes into the festival itself.

This festival runs on a single bilingual WordPress platform that covers what a festival needs end to end: the public website, ticket sales and marketing, and the organisers' back office for facilitators, volunteers and vendors. Data that used to live in spreadsheets and forms is now collected, reviewed and published from one place.

E-commerce · ERP integration

A publisher's bookshop connected to its ERP: orders out, stock in

Every paid order arrives in the ERP as an invoice ready for picking, and the shop's stock follows the warehouse. Nobody retypes an order or a stock figure.

This publisher keeps its invoicing and warehouse stock in Directo (an ERP widely used in Estonia). A custom plugin connects the webshop to it in both directions. When a payment completes, the order is sent to Directo as an invoice for picking. Every four hours the shop reads the stock levels from Directo, and a ledger of recent sales subtracts the copies whose sale Directo has not processed yet. Failed runs and mismatches are logged and reported by email.

Calendars · Google integration

A booking and events calendar that lives inside the organisation's Google Calendar

A booking or event is entered once. The organisation's Google Calendar, the calendars on the website and the registration sheet update themselves.

A custom WordPress plugin connects five content types (bookings, tournaments, hobby clubs, trainings and events) to the organisation's Google Calendar. Publishing or editing a post creates or updates the matching calendar event and unpublishing removes it; unchanged posts are skipped. On the website, visitors get week, month and overview calendars with filters in two languages, and completed shop orders are recorded in a registration spreadsheet for the organisers.

E-commerce · Supplier integrations

An online department store fed by four supplier catalogues

More than 50,000 products from four suppliers are imported, translated and published without anyone entering a product by hand.

This online department store sells more than 50,000 products that arrive from four supplier feeds. Import jobs run on a schedule and are guarded against bad files; titles and descriptions are translated from Polish with a learned product glossary; images are processed and served from object storage; and a product goes live only after its image, description and title pass the publish gates. The client's own warehouse stays the source of truth for stock.

E-commerce · Checkout & tracking

A publisher's bookshop with checkout and tracking rebuilt around real orders

Analytics used to see about one order in ten. Purchases are now reported server-side, from the order itself.

This publisher's webshop uses a custom cart with Montonio (Baltic bank-link payments and shipping). Client-side analytics recorded only about one in ten real orders, because buyers leave for their bank and often never come back. Purchases are now reported server-side from the order itself, to both GA4 and Meta (Conversions API), with de-duplication, hashed customer data and the visitor's session attached.

Request a site review →

Security & reliability · Incident response

Security incident resolved: a site offline ten hours a month, fixed for good in fifteen minutes

About ten hours of downtime a month, for months. Once the pattern was found in the server logs, the permanent fix took about fifteen minutes.

A business website kept dropping offline, adding up to roughly ten hours of downtime a month, and the outages had been growing for months. It looked like a WordPress or plugin fault, but the cause sat outside WordPress: a public redirect endpoint on the same server looked up each request by calling the main site over HTTP with no timeout. Five simultaneous bot requests were enough to occupy every PHP worker while each waited for a sixth, and the web server's timeout freed only one worker at a time, so the pool never drained. Once the pattern was visible in the server logs, the permanent fix took about fifteen minutes.

Request a site review →