Engineering service
Browser & Desktop Engineering Consulting
Access to senior browser and desktop engineering expertise before you commit to an expensive technical direction. You get clarity on architecture, feasibility, cost drivers and the right technology choice: build, fork, extend or embed.
- 15+ years of experience
- 300+ projects delivered
- Clients worldwide
- NDA available
Overview
What this is, and when it is the right call
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 scoped to your questions and ends 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 honest 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 we engineer: Browser & Desktop Engineering Consulting
Requirements Workshops
Structured sessions with your product and engineering leads to turn a vague idea into a written, testable requirement before anyone estimates the work.
Team Capability Assessment
An honest look at whether your current team has the Rust, C++ or browser-internals experience a chosen approach would require, and what hiring or training it implies.
RFP and Vendor Requirements
Technical requirements written for a request for proposal, so vendor bids can be compared against the same specification instead of each vendor's own framing.
Security and Compliance Review
A check of a proposed or existing browser, extension or desktop architecture against the security and compliance requirements it needs to meet.
Post-Incident and Post-Mortem Reviews
An outside read on what went wrong in a browser or desktop project that stalled or shipped with problems, and what would need to change to continue it.
Technology Landscape Briefings
A briefing on the current state of an engine, framework or platform, such as a change to Manifest V3 or a new WebView capability, aimed at a specific decision you are facing.
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 it can be revisited by people who join the project later or by a different team entirely.
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, Not a Template
An engagement is built around the specific decisions in front of you, not a standard checklist applied to every client.
A Reference for Future Hires or Vendors
Written specs and reasoning that a new engineer, a new vendor or your own team months later can pick up without re-deriving the logic.
Our approach
How an engagement runs
Scope the questions
We agree on the specific decisions you need help with and what material we can review.
You get: A written scope
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
A few cases where this approach may not be the best choice for you.
- You already have a settled plan and want it built. You can skip this and go straight to a build engagement.
- 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 behind our browser & desktop engineering consulting work.
Chromium
Gecko
WebKitWebExtensions (Manifest V3)CEF
WebView2
Electron
TauriFAQ
Questions engineers ask before starting
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.
Proof
Related production work
Enterprise & Security
Total Security Browser
A security-focused Chromium browser for a large enterprise company, with its own installer, updater and hardening.
- Chromium
- Omaha
- C++
Multi-Session Browsers
DemoStory Browser
A C++ multi-session browser where different user accounts share one window, with a payment system and admin dashboard.
- C++
- Chromium
- Multi-session
Web3 & Decentralized
Minego Browser
A next-generation Web3 browser with a wallet protocol, built-in VPN, side panel, gaming, launchpad and DAO integration.
- Chromium
- Web3
- Wallet
Our services
Related services
Explore more services that work alongside this one.
Talk to a Browser Engineer
Get Clarity Before You Commit
Bring the idea to a browser engineer. You will leave knowing what is realistic, what drives cost and which technology to build on.
