Engineering service
Browser Engineering Consulting
Before you commit budget to a browser or desktop project, our senior browser engineers help you decide whether to build an extension, fork a browser, embed one or build a desktop app. You get a written recommendation that covers the architecture, the cost drivers and the risks.
- 11+ years of experience
- 300+ projects delivered
- Remote team, clients worldwide
- NDA on request
Overview
What it is and when it fits
Browser and desktop projects have expensive wrong turns. Choosing an extension when you needed a fork, or a fork when an embedded browser would do, can cost months. Consulting is a way to make that choice with evidence before you build.
An engagement is remote, scoped to your questions and led by senior engineers from our browser team. Most run for one to three weeks and end with written output you can use whether or not you hire us to build. We report risks as they are, including when the answer is that the project is not worth doing.
Who this is for
- Founders and product leads deciding how to build a browser-based or desktop product.
- Engineering teams weighing an extension, an embedded browser, a fork or an app framework.
- Companies holding a quote from another vendor that they want checked before signing.
- Teams inheriting a codebase, especially a browser fork, and needing an independent assessment.
How it works
What a consulting engagement produces
Each stage ends with something written that you keep.
Discovery
We learn the product goal, the constraints and what has already been tried.
You get: A shared statement of the problem
Options
We lay out the realistic technical approaches and how each one would work.
You get: A comparison of the viable approaches
Risk and cost drivers
We identify what could go wrong and what makes each option expensive to build and maintain.
You get: A risk register and a list of effort drivers
Recommendation
We recommend one approach and explain why the others were set aside.
You get: A recommendation memo
Roadmap
We break the recommended approach into milestones with dependencies and decision points.
You get: A milestone roadmap
What we offer
What's included
Feasibility review: build, fork, extend or embed
Whether you need an extension, an embedded browser, a custom Chromium or Firefox build or a desktop app, and what drives the effort for each. It ends with a written recommendation.
Architecture review
A review of a planned or existing design: where each change lives, how it survives upstream upgrades, and how signing, updates and security fixes will work.
Browser fork audit
A written assessment of a Chromium or Firefox fork: how the patches are organized, how far it is from upstream, how security releases are handled and how it is built and released.
Second opinion on a vendor quote
Scope gaps, risky assumptions and missing maintenance costs in another vendor's proposal, with questions to put back to the vendor.
Extension and desktop app review
The same written assessment for a browser extension or an Electron or Tauri app: security settings, dependencies, upgrade debt and the release process.
Stalled project review
An outside read on a browser or desktop project that stalled or shipped with problems, and what would need to change to continue it.
Deliverables
What you get
- 01
Feasibility memo
A written answer on whether the idea is technically and practically achievable, and under which conditions.
- 02
Architecture proposal
A described design for the recommended approach, with diagrams and the reasoning behind key choices.
- 03
Effort drivers and risk register
A list of what determines cost and duration, and the risks with their likelihood, impact and mitigation, without invented figures.
- 04
Roadmap with milestones
A phased plan that shows what to build first and where to stop and reassess.
- 05
Review of an existing codebase
A written assessment of code quality, security posture, upgrade debt and maintainability.
- 06
Second opinion on another vendor's proposal
A review of a quote or plan, covering scope gaps, technical assumptions and questions to ask the vendor.
Compare
The main risk of each approach
Every approach has a failure mode that is easy to overlook at the start. Naming it early makes it manageable.
| Approach | Main risk | How we reduce it |
|---|---|---|
| Browser extension | Store policy or browser API changes can break or remove the extension | Use standard APIs, keep permissions minimal and plan for policy review and manifest changes |
| Embedded browser | Version drift and security patching of the bundled engine | Choose an engine with a clear update path and define who ships updates before building |
| Custom Chromium or Firefox fork | Falling behind upstream security releases | Keep patches small and isolated, and set up a repeatable process for rebasing onto new releases |
| Electron or Tauri app | Framework upgrades and differences between WebViews | Keep the native layer thin, test on every target platform and schedule regular upgrades |
Why it matters
What this gives you
A written decision record
The reasoning behind a recommendation is written down, so people who join the project later, or a different team, can revisit it.
Assumptions tested early
Risky assumptions are checked with small experiments during the engagement, before a team commits months of engineering time to them.
Scoped to your questions
An engagement is built around the decisions in front of you, not a standard checklist applied to every client.
Scope and cost agreed up front
The questions, the material we review, the deliverables, the schedule and the cost are set out in a written proposal before work starts.
Our approach
How a consulting engagement runs
Scope the questions
We agree on the decisions you need help with, the material we can review and the schedule. We sign an NDA first if you need one.
You get: A written scope and schedule
Review and research
We read code, documents and constraints, and test assumptions with small experiments where needed.
You get: Findings and evidence
Working session
We walk your team through the options and risks and hear what we have missed.
You get: Agreed priorities and open questions
Written recommendation
We deliver the memo, architecture notes and roadmap that record the decision and its reasoning.
You get: The final documents
When this is not the right fit
- You already have a settled plan and want it built. You can skip this and start with a build project.
- You want a guaranteed cost and date from a document alone. Estimates depend on decisions only prototyping settles.
- Your question is outside browsers and desktop software, such as general business or legal advice.
Tech stack
Technologies we use
The engines, APIs and tools we use on this service.
Chromium
Gecko
WebKitWebExtensions (Manifest V3)CEF
WebView2
Electron
TauriFAQ
Common questions
You get written documents: typically a recommendation memo, the risk register, effort drivers and a roadmap, depending on what we scoped. They belong in your files and are useful whether or not we build anything.
Senior engineers from our browser team, the same people who build and maintain Chromium forks, extensions and desktop apps for clients. The work is remote: we review code and documents, run small experiments where needed, and walk your team through the findings in a working session.
Yes. We read the proposal for scope gaps, technical assumptions that may not hold and missing items such as maintenance and updates. You receive a list of findings and questions to put back to the vendor.
No. Sometimes the finding is that a simpler approach works, that the project should wait, or that another team is better placed to build it. The documents are yours either way.
Most engagements take one to three weeks. As a typical guide, a feasibility review or a second opinion on a vendor quote takes about 3 to 5 working days, and an architecture review or a fork audit takes about 1 to 2 weeks, depending on how much code we need to read. The written scope confirms the schedule before we start.
Yes. We check how the patches are organized, how far the fork is from upstream, how security releases are handled and how the build and release process works. You receive a written assessment with priorities.
Proof
Related production work
Security browsers
Total Security Browser
A hardened Chromium browser for Total Security Limited in the UK. We built the browser, its installer and its Omaha-based auto-updater.
- Omaha
- Installer
- Security hardening
Multi-session browsers
DemoStory
A Chromium browser for live product demos, where each tab can be logged in as a different user. We built the multi-session core, payments and admin dashboard.
- Multi-session
- Payments
- Admin dashboard
Web3 browsers
Minego Browser
Minego’s Web3 “Super Browser”. We built it on Chromium with a wallet protocol, a VPN, a side panel and entry points to Minego’s games, launchpad and DAO.
- Web3
- Wallet
- VPN
Our services
Related services
Start a project
Get a second opinion before you commit
Tell us what you are planning or what you have inherited. We will suggest the smallest review that answers your question.
