Engineering-led custom software
O2 Tech Labs designs and builds WordPress and Next.js platforms, custom software, and integrations, and takes on the hard problems underneath them: architecture, data, performance, and the parts nobody notices until they break.
Senior engineering across
Most software problems trace back to decisions: what to build, where it runs, how it connects, what happens under load. O2 is a senior engineering partner for teams that need those decisions made well, and the software built to match.
Capabilities
Our deepest experience is in WordPress platforms, Next.js applications, systems integration, and performance and troubleshooting work. We also build custom software and help with architecture.
We build custom themes and block themes, custom blocks with real data models, and plugins that connect WordPress to the rest of your stack. We also run complex content migrations, set up publishing feeds that distribute content to other platforms, and manage multisite networks with functionality shared across sites. Editors get a fast, pleasant interface with sensible limits, and engineers get code they can maintain.
Layers reached
Component systems your team can extend, written in TypeScript. Each route gets static generation, server rendering, or streaming, depending on what it serves. We go headless when the extra complexity pays off and build a solid monolith when it doesn’t.
Layers reached
We design the middleware, webhooks, and sync jobs between CRMs, payment providers, SaaS tools, authentication systems, and internal APIs. We work out with you which system owns each field, and build in retries and monitoring so drift between systems shows up early.
Layers reached
Slow pages, failing integrations, production bugs that only appear under load, migrations nobody wants to run. We work from evidence (traces, profiles, logs, field data) until we find the root cause, fix it there, and add tests or monitoring that catch it if it returns.
Layers reached
We design and build software from real requirements: internal tools that remove manual work, SaaS products, customer-facing applications, and the backend services behind them. When an existing system is holding you back, we modernize it in stages, planned around keeping the business running.
Layers reached
We define service boundaries, API contracts, data flows, and deployment strategy, and choose hosting for the workload and the team that has to run it. For systems that already exist, we also run architecture reviews and technical audits.
Layers reached
The engineering layer
Where work happens, where data lives, and how failures are handled all affect performance, reliability, and maintenance. These decisions evolve as your business grows. Here are five areas that shape how a system works.
Five areas, numbered on the diagram
Decide what can be served from the edge, what needs fresh data, and how cached content stays current.
Define where rendering, business logic, APIs, and authentication belong so the application stays maintainable.
Choose how data is stored and when work should run in the background, including how retries avoid duplicate actions.
Define how connected services exchange data and how failures, timeouts, and service limits are handled.
Use logs, metrics, traces, and alerts where appropriate to understand system behavior and investigate problems.
Field notes
These are composites based on the kind of work we take on, not accounts of specific clients. The details vary from client to client, but the same problems keep coming up.
Example scenario · Scaling
Response times climb from under a second to eight or more during the weekly peak. Restarting the servers buys an hour.
Request traces, slow-query logs, and connection-pool metrics, then a load test that reproduces the Monday peak on staging.
A reporting query added months earlier locks the orders table. Under load, checkout requests queue behind it until the connection pool runs dry.
Reporting moves to a read replica, the missing composite index goes in, and pool limits and timeouts get set. The load test joins CI so the regression can’t come back unnoticed.
Example scenario · Integration
Duplicate contacts, orders missing from the CRM, and a sales team working from stale data. Nobody trusts either system.
Map every write path between the systems (webhooks, nightly imports, manual exports) and compare records field by field.
Two integrations written years apart, each treating itself as the source of truth, with webhooks that fail silently and never retry.
One documented owner for every field, an idempotent sync service with a retry queue and dead-letter review, and a daily reconciliation report that flags drift.
Example scenario · WordPress
The WordPress admin crawls, autosaves collide, and the editorial team has quietly started drafting in Google Docs.
Profile editor asset loading, the REST requests fired on load, block registration, and the plugin stack.
Dozens of blocks registered globally with heavy dependencies, plus a plugin firing uncached REST requests on every editor load.
A purpose-built block library with lazy-loaded assets and server-side rendering, cached endpoints, and a plugin audit that removes what editors never use.
Example scenario · Performance
Search Console flags failing URLs, organic traffic dips, and the site feels slow on phones, even though it looks great on a desktop.
Field data against lab data, LCP element analysis, long-task tracing for INP, and layout-shift attribution, template by template.
A hero image discovered late, third-party scripts blocking the main thread, and web fonts shifting the layout as they load.
Prioritize the LCP resource, defer and isolate third parties, reserve layout space, and add performance budgets to CI so every template is held to the same thresholds.
Google’s “good” thresholds, measured at the 75th percentile of real-user data.
Example scenario · Modernization
Every change takes weeks, deploys are manual and nerve-racking, and the one person who understood the system has moved on.
Read the code, map dependencies and data, build a reproducible local environment, and put tests around the paths that make money.
The platform’s age matters less than its lack of seams. Business logic is tangled into presentation, so there’s no safe way to change one part without risking the rest.
Introduce seams and an automated deploy pipeline first, then replace the system one bounded piece at a time while it keeps running.
WordPress
We build custom editorial experiences, maintainable themes and plugins, WordPress sites connected to the rest of your systems, and multisite platforms that run many sites from one codebase. That includes the work around a large content platform: complex migrations, publishing feeds, and technical SEO across the whole platform.
{
"apiVersion": 3,
"name": "o2/service",
"title": "Service",
"category": "o2-tech-labs",
"attributes": {
"summary": { "type": "string" },
"layers": { "type": "array", "default": [] },
"stack": { "type": "array", "default": [] }
},
"supports": {
"align": ["wide", "full"],
"spacing": { "padding": true },
"color": { "background": true }
},
"editorScript": "file:./index.js",
"render": "file:./render.php"
}GET /wp-json/wp/v2/o2_service?slug=wordpress-engineering
200 OK · application/json
[{
"id": 214,
"slug": "wordpress-engineering",
"title": { "rendered": "WordPress engineering" },
"summary": "Themes, editorial tools, migrations, and multisite.",
"layers": ["interface", "application", "apis", "data"],
"stack": ["PHP", "Gutenberg", "REST API", "HubSpot"],
"modified": "2026-10-30T14:20:00"
}]Content is stored as structured data, not a blob of HTML, so it can be queried, migrated, and reused.
Spacing, color, and type come from design tokens, so editors can choose among options without breaking the design.
The server renders and caches the output, so pages are fast, crawlable, and free of markup drift from the editor.
Custom REST fields return the same data as JSON, ready for a Next.js front end, a publishing feed, or HubSpot.
JavaScript applications
We build web applications on Next.js and the wider JavaScript ecosystem, and connect them to the databases and services a growing product needs.
01
Next.js is our default for applications. For content sites we also use Astro, which ships very little JavaScript, and Gatsby, which builds static sites from many data sources.
02
MongoDB when your data is a set of flexible documents. Neon when it needs Postgres: relational, serverless, and able to branch a copy of the database for each preview.
03
Most apps need to talk to other systems. We connect them to WordPress as a headless CMS, HubSpot, payments, sign-in, search, and email, with retries and monitoring on every connection.
04
The tools we reach for at each layer of an application. We choose from them per project, and most apps use only a few.
Next.js
We build React and Next.js applications in TypeScript, with component systems your team can extend. Each route gets the rendering strategy that fits what it serves.
| Route | Strategy | Because |
|---|---|---|
/ | Static, hourly | Shared by everyone |
/pricing | Static | Changes on deploy |
/docs/[slug] | Static, from CMS | Thousands of pages |
/account | Server-rendered | Personal to each user |
/dashboard | Streamed | Slow data, fast shell |
/api/search | Cached, 60 s | Hot and read-heavy |
Our default
Headless when it earns its complexity. A well-built monolith when it doesn’t.
SEO & syndication
How a business shows up online, in search results, news apps and the feeds partners pull from its site, is part of its identity. We build the technical side of it: fast, stable pages, markup search engines can read, sitemaps that keep up with your content, and feeds built to each syndication partner’s spec.
Core Web Vitals affect rankings as well as conversions. We hold LCP, INP and CLS to budgets, and the build fails when a change breaks one.
Semantic HTML, schema.org structured data, canonical URLs and complete metadata, so search engines understand each page without guessing.
XML sitemaps generated from your content and updated on publish, with robots rules that point crawlers at the pages that matter.
Custom feeds for Yahoo, MSN, NewsBreak, SmartNews, Flipboard, Yardbarker and other partners, each built to the partner’s spec, validated before it ships, and monitored afterward.
Performance, measured
Google’s Core Web Vitals measure how real visitors experience a page: how quickly the main content appears (LCP), how fast the page responds to input (INP), and whether it holds still while it loads (CLS). They’re one of the signals Google uses to rank pages, and slow pages lose visitors long before rankings matter.
We treat performance budgets like tests. This site runs Lighthouse on every pull request, on mobile and desktop, and a change that misses a budget doesn’t ship. The report here is this page’s own.
Lab scores are the starting point. After launch, field data from real visitors, in Search Console and Chrome’s UX Report, shows whether the numbers hold up.
The same on mobile and desktop.
| Metric | Mobile | Desktop |
|---|---|---|
| First Contentful Paint | 1.2 s | 0.3 s |
| Largest Contentful Paint | 1.2 s | 0.6 s |
| Total Blocking Time | 10 ms | 0 ms |
| Cumulative Layout Shift | 0 | 0 |
| Speed Index | 1.2 s | 0.3 s |
Mobile is Lighthouse’s simulated mid-range phone on a throttled 4G connection.
Where we fit
We build the platform search engines and partners rely on. Keyword and content strategy stay with your marketing team or SEO partner.
AI in our workflow
We use AI tools every day in our development and architecture work. They help us research faster, keep up with a fast-moving ecosystem, and spend less time on repetitive tasks.
Decisions stay with our engineers. Someone who understands the code reviews every change, and architecture and security calls are made by people.
Approach
The engineers who scope your project are the ones who build it.
Alvaro Oropesa
President & founder
I’m a bilingual software engineer with more than 15 years in web and application development. My deepest experience is in custom WordPress work (themes, plugins, and Gutenberg blocks), HubSpot CMS, and React and Next.js applications, along with the integrations between them, such as REST endpoints that connect WordPress to HubSpot CRM.
I stay involved in our projects from the first technical conversation through delivery, working with the rest of the O2 team. Accessibility, SEO, performance, and security are part of how we build from the start.
We start by reading the code, the infrastructure, the analytics, and the support tickets, and by talking to the people who use the system every day.
We write down each option with its trade-offs: cost, risk, time, and what it makes easier later. You make the call with all of that in front of you.
We ship in small, reviewable increments, with automated checks, tests where they pay for themselves, and preview deployments where the hosting supports them.
You get documentation, runbooks, and a walkthrough so your team can own what we built. If you’d rather, we stay on as your senior engineering partner.
Start a project
A new build, a platform that’s outgrown its original design, or a problem nobody has managed to pin down: send a few lines, and you’ll hear back from an engineer.