DEV Community: Ivan Assenov

I got tired of my web app silently breaking after every deploy, so I built an open source QA platform

Ivan Assenov — Mon, 26 Jan 2026 19:43:47 +0000

The breaking point

I run a company called Scale Campaign. One of our products is a batch geocoding platform with a Laravel backend, a Vue.js frontend, and a TerriaJS-based map viewer on a separate subdomain.

It's the kind of app that has a lot of surface area: landing pages, authentication flows, a file-upload pipeline, an interactive map, payment pages, an admin dashboard, and help docs. Multiple JS bundles, multiple CSS builds, third-party scripts.

And things kept breaking silently.

A deploy would go out. Everything looked fine. Then, a week later, someone would mention that the file upload wasn't working on the pricing page. Or I'd discover that a third-party script was throwing TypeError on three pages. Or Google Search Console would flag that our OG images were missing. Or performance had regressed to a 6-second LCP on mobile, and nobody noticed.

The worst part? Every time I investigated, the problem had been there for days.

The workflow that doesn't scale

My debugging process was:

Open Chrome DevTools
Check one page at a time
Run Lighthouse on that page
Check the console for JS errors
Inspect meta tags manually
Repeat for the next page
Forget which pages I already checked

For a site with 75+ distinct pages, some requiring authentication, this takes forever. And I'd only do it when something was already broken.

I wanted something that would just tell me: "Here's everything wrong across your entire site right now."

What I built

https://github.com/acenji/lighthouse is an open source QA platform that combines three tools (for now) into one workflow:

Bulk Lighthouse audits - for local and production environments

Instead of auditing one URL at a time, ScaleLighthouse crawls your site and runs Lighthouse across every page. You get a dashboard showing performance, accessibility, SEO, and best practices scores for your entire site at a glance.

pnpm cli --site https://csv2geo.com --server-port 5678

Open localhost:5678 and you're looking at every page's audit results.

Playwright smoke tests (zero test code) - for local and production environments

This is the part that saved me the most time. The smoke test framework is data-driven — you write a config file

describing your site, and it generates all the tests automatically.

Here's what the config looks like for CSV2GEO:

const csv2geo: ProductTarget = {

name: 'csv2geo',

baseUrl: 'http://localhost:8000',

baseUrlEnv: 'CSV2GEO_URL',

pages: [

{ path: '/', name: 'Homepage', selectors: ['#app', 'nav'] },

{ path: '/features', name: 'Features' },

{ path: '/pricing', name: 'Pricing' },

{ path: '/help', name: 'Help Center' },

{ path: '/inside/dashboard', name: 'Dashboard', auth: true,

selectors: ['.dashboard-grid'] },

{ path: '/inside/tasks', name: 'Tasks', auth: true },

],

auth: {

strategy: 'form',

loginUrl: '/login',

fields: {

'#email': '${CSV2GEO_EMAIL}',

'#password': '${CSV2GEO_PASSWORD}',

},

submitSelector: 'button[type="submit"]',

successIndicator: '/inside',

},

allowedErrors: ['analytics', 'hotjar', 'google'],

seo: {

pages: [

{ path: '/', title: /CSV2GEO/i, ogImage: /.+/, canonical: 'https://csv2geo.com/' },

{ path: '/features', title: /Features/i },

{ path: '/pricing', title: /Pricing/i },

]

}

};

No test code. That config generates tests that:

Visit every page and verify the HTTP status
Check that required DOM elements are visible
Catch every JavaScript error (filtered for third-party noise)
Validate SEO meta tags, OG images, and canonical URLs
Log in and test authenticated pages
Run on both localhost and production with one command

npx playwright test # all environments

npx playwright test --project="csv2geo [prod]" # production only

npx playwright test --ui # interactive UI

Multi-step flow testing

The file upload on CSV2GEO is a multi-step process — select a file, configure columns, and submit. When it broke, users were the first to find out. Now there's a flow test:

flows: [{

name: 'CSV file upload',

auth: true,

steps: [

{ action: 'goto', path: '/inside/dashboard' },

{ action: 'click', selector: '#new-task-btn' },

{ action: 'upload', selector: '#file-input', value: 'fixtures/sample.csv' },

{ action: 'wait', selector: '#column-mapping', timeout: 10000 },

],

expectSelectors: ['#column-mapping'],

expectNoJsErrors: true,

}]

Real-user metrics (CrUX)

The platform also pulls data from Chrome's UX Report API, so you can see real INP, CLS, and LCP trends from actual users — not just synthetic tests.

What it catches

Since deploying this against CSV2GEO, it's caught:

A TypeError in the map viewer caused by a missing null check after a refactor
An OG image returning 404 on three pages
A render-blocking script that pushed LCP from 2.1s to 5.8s
A broken CSS class reference that made the dashboard invisible on Firefox
A third-party script failing silently and swallowing form submissions

All of these were found within seconds of running the tests — not days later from a user report.

Tech stack

It's a pnpm monorepo:

┌─────────────┬─────────────────────────────────────┐

│ Package │ What it does │

├─────────────┼─────────────────────────────────────┤

│ cli │ Command-line entry point │

├─────────────┼─────────────────────────────────────┤

│ core │ Scanning engine and route discovery │

├─────────────┼─────────────────────────────────────┤

│ server │ API serving scan results │

├─────────────┼─────────────────────────────────────┤

│ client │ Vue 3 dashboard (Vite) │

├─────────────┼─────────────────────────────────────┤

│ smoke-tests │ Playwright test framework │

├─────────────┼─────────────────────────────────────┤

│ crux-api │ Nitro server for CrUX data │

└─────────────┴─────────────────────────────────────┘

Requires Node.js 20+. MIT licensed.

Getting started

git clone https://github.com/acenji/lighthouse.git

cd lighthouse

pnpm install

# Run a Lighthouse audit

pnpm cli --site https://your-site.com

# Run smoke tests

cd packages/smoke-tests

npx playwright install chromium

npx playwright test --ui

The repo

https://github.com/acenji/lighthouse

If you're maintaining a web app with more than a handful of pages and you're tired of things breaking silently — give it a try.
Star the repo if it's useful, and open an issue if you run into anything.

Feedback and contributions welcome.

Note: credentials in the config examples are loaded from environment variables (.env file), never hardcoded.

Avoiding Pitfalls in the Race to Build Super Apps.

Ivan Assenov — Sun, 16 Feb 2025 20:46:40 +0000

Before diving into the pitfalls, one might ask:

Wait, what exactly is a super app?

To understand this, we need to rewind to the meteoric rise of BlackBerry. This little Canadian company, led by its visionary co-founder Mike Lazaridis, made waves with an ambitious concept. In his 2010 keynote speech at the Mobile World Congress, Lazaridis coined the term Super App and described it as follows:

"A Super App for BlackBerry smartphones is an app that delivers a compelling user experience by leveraging the unique capabilities of the BlackBerry platform. Super Apps are the kind of apps that people love and use every day because they offer such a seamless, integrated, contextualized, and efficient experience."

This vision planted the seed for what we now recognize as Super Apps—platforms that seamlessly integrate diverse services into one ecosystem, providing unmatched value to users.
Source: RIMarkable

In other words, to put it simply, a super app is an app that becomes an inseparable part of your daily life. Wherever you go, you use it—not because someone tells you to, but because it’s convenient. It has everything you need, exactly where you want it. It does everything you want, and most importantly, it works seamlessly, 24/7.

Sounds simple, right? Not so fast. Building a super app has proven to be one of the most challenging feats in modern app development. While the concept seems straightforward, the reality is far more complex. Today, there are only a handful of true super apps, and they primarily fall into one category: social messaging platforms integrated with mobile payment systems.

Imagine a restaurant serving super apps on its menu. Surprisingly, they would look almost identical: instant messaging, short social interactions, and an integrated mobile payment system—often built and managed by the same vendor.

Another notable example is X (formerly Twitter) and its aspirations to become a super app. With approximately 600 million monthly active users, X is making a determined push into the super app market. However, key ingredients are still missing: its own payment wallet and a significantly improved messaging system. The rest? They already have it.

You get the idea: there’s nothing particularly groundbreaking about super apps so far. They seem tailor-made for giant tech vendors, and perhaps a better name for them would be “whale apps”.

At their core, the formula is simple: Social app + Wallet = Super App.

That equation is also where the risk lies: losing the next 20 years of mobile app development to a narrow, oversimplified idea of what a super app should be.
The argument here is that super apps may have nothing to do with social apps at all. In fact, they may—or may not—have only minimal ties to financial wallets. If we look closer, this actually describes most modern business platforms today.

We all need a wallet, right? Until we don’t.

But let’s take this one step at a time.
While every person is unique, people also share common patterns—sometimes so much so that entire groups can exhibit overlapping behaviors and needs.
Now, imagine a workplace: a company juggling multiple apps, multiple tools, and endless systems. They just keep coming—each with its own security requirements, updates, and lost passwords. It’s a logistical nightmare.

Or take a hobby group, for example—whether it’s biking or skiing—where people share everything about their activities. Building a super mobile app tailored specifically for these groups, for their needs, seems like a logical idea, right?

But is anyone actually doing it?

The reality is that creating and supporting such an app with modern-day technology is extremely expensive. It’s a financial gamble that could bankrupt even the most ambitious developer.
I still remember sitting in a company meeting where the idea of a super app began to float around. Everyone debated what it would include, feature by feature. Then, at the very end, my boss spoke up with a single question:

“But who will build it?”

Software is expensive.

Very expensive. And a super app? It must be astronomically expensive, right? After all, if it weren’t, someone would have built it already.

How about no?
What if we flip the script and say, no, it doesn’t have to be that way?

NoCode Super App Builder

What if we introduce the NoCode Super App Builder, a tool that empowers anyone to create an endless number of super apps? A platform where users can mix and match from an unlimited library of mini apps—the very tools and services already known in the market.

And because everything operates under the same umbrella—on the same device, using the same protocols—building, distributing, and adjusting a super app becomes easy.
Users can choose which mini apps to upload and use, but here’s the key difference: these mini apps won’t be like the apps we know today. They can share information, and the user—or the app owner—can decide how that data flows and to what degree it is shared.
Now, we’re talking about a network of apps—working together seamlessly, under the same protocols, on the same device, using shared data.
Who’s still talking about payment wallets or social messaging? That’s yesterday’s conversation. We’re talking about the ocean of data—a vast world of possibilities, all available and ready to use.

The answer lies in NoCode—and it has to be 100% NoCode. Why? Because the moment we introduce humans with their low-code injections, we open the door to inconsistency. It will never work everywhere, every time. Bugs will appear, and it will collapse—just like BlackBerry did.
For this to succeed, it must be entirely NoCode. And over time, it must be run by AI.
At first, AI might handle 2% of the build, then 3%, but I envision a future where 100% of the process is driven by AI. A world where super apps are created, maintained, and scaled—seamlessly and autonomously.

Super App Builder Components

So, what are the key components that this Super App Builder (SAB) would include?
Notifications
Actions
Payment Wallet
Geolocation Services
AI-Generated UI with a library of around 200 components
NoCode Unlimited Native Mobile Mini Apps
NoCode Web Apps
NoCode TV Apps
Sharing/Privacy Module for complete control of data flow
Test Certificates for code coverage and reliability
Additional Modules as needed
With SAB, users gain the power to create seamless, customizable, and robust super apps that function flawlessly across platforms.

NoCode Super App Operating System - SAB OS

As a variation, we can take this concept a step further and create SAB OS—an operating system for building super apps.
For this to become a reality, a few critical elements must fall into place:

Funding or Open Sourcing: The Super App Builder must either be well-funded or made open source to encourage contributions. This is crucial because it requires a critical mass of users to gain traction in the market and attract businesses, design agencies, and product teams.
Database Independence: The tool must be detached from any single database—and by “database,” we mean anything related to data and how it is fetched into the system. Sounds crazy, right? Not so much.

Many businesses already have their infrastructure built around existing data and databases. Instead of forcing them to migrate, why not adapt to what’s already in place? SAB OS can connect, build bridges, and seamlessly integrate with their existing data.
The data could operate in read-only mode, or allow for read/write capabilities—offering flexibility and control based on business needs.
The biggest question remains: why haven’t established companies built this yet?
The answer couldn’t be simpler: it’s too expensive—not just financially, but in terms of redefining who they are. Building a super app would mean reconstructing their business around a new identity, and for many, that cost is simply too high to bear.

Instead, the new trend should focus on super app no-code builders that come with one idea in mind: Build Your Vision with a Nocode Super App Builder.

Written by Ivan Assenov.