Browser Software vs Desktop App: Why Figma Accepted a Three-Year Build
Short answer: Choose the harder architecture only when it removes a customer constraint competitors cannot cheaply remove and that difference can be tested before the full build. Price the extra engineering time, performance risk and delayed revenue against a narrower alternative. Continue while prototypes prove the structural advantage with target users and runway still funds a sellable release; stop when the architecture is merely technically impressive or customers value ordinary features more.
Architecture is usually an implementation decision. Sometimes it determines who can use the product, how people collaborate and what the product can promise.
That does not make technical difficulty a virtue. A three-year build is justified only when the hard choice creates customer behaviour that a simpler product cannot.
Use the Structural Differentiation Bet
The Structural Differentiation Bet tests whether technical architecture creates a durable market position through five linked claims.
| Claim | Evidence before full commitment | Failure signal | |---|---|---| | Constraint | A valuable customer job is blocked today | Problem is occasional or cosmetic | | Mechanism | Architecture directly removes the block | Benefit could be added to simpler route | | Prototype | Critical behaviour works at useful quality | Demo succeeds only under ideal conditions | | Adoption | Target users change behaviour because of it | Users praise technology but retain old workflow | | Runway | Cash covers build, testing and release | Revenue depends on an unbounded schedule |
My view is that a start-up should accept a long technical build only for a structural difference, not feature completeness. Ship a narrow version of the hard advantage before building the familiar edges around it.
What Figma's browser decision created
Dylan Field and Evan Wallace began exploring browser technology in 2011 and started Figma in 2012. Figma's founder conversation says WebGL, which uses a computer's graphics processor through the browser, was central to what became possible. The team explored several ideas before focusing on a design tool.
Figma's filing documents provide unusually clear chronology. Its registration statement says the founders spent three years building, testing and iterating before launching Figma. The browser was not only a delivery choice. It supported cloud-first access and live collaboration, a behaviour desktop design workflows handled poorly at the time.
Field has said early users included companies such as Notion and Coda that valued cloud-first browser performance. TechCrunch's history notes that some designers initially resisted the collaborative premise and that browser technology had to catch up with the vision.
The case does not prove browser software is superior to desktop software. It shows a hard architecture can become positioning when it enables a customer experience, in this case shared access and collaboration, that defines the product.
State the blocked job before the technology
Write what customers cannot do adequately with existing products. “Our software runs in a browser” is a property. “A colleague can open the same file from a link and edit with you without installing software or reconciling versions” is a customer difference.
Interview users around the current workflow. Count file exports, version conflicts, hand-offs, installation delays, inaccessible devices and review cycles. Ask what those failures cost in hours, missed approvals or rework.
If the problem can be solved with a shared review link attached to a desktop tool, a full browser editor may be unnecessary. If simultaneous editing is central and every participant must access the source, architecture may be the mechanism.
Positioning becomes credible when the product's structure repeatedly delivers the claim. A slogan about collaboration cannot compensate for latency, crashes or missing core functions.
Prototype the technical impossibility first
Build a vertical slice of the hardest interaction, not a broad but shallow application. For collaborative design, that might include rendering a complex document, editing two objects simultaneously, recovering after a connection loss and opening through a shared link.
Set measurable minimums for load time, response latency, data integrity, browser coverage and recovery. Test on ordinary target-user hardware and real networks, not only development machines.
Invite a small group whose workflow contains the blocked job. Observe whether they complete it and choose the prototype over their workaround. Do not ask whether the vision sounds exciting. A working demo that nobody returns to is not architectural validation.
Security, privacy, accessibility, software licensing and data-location duties vary by market and customer. Obtain qualified advice and design them into the architecture rather than adding them after enterprise buyers object.
Compare the long build with a narrow sellable wedge
A structural bet does not require three years of silence. Identify the smallest customer and workflow that need the advantage enough to accept limited features.
Possible wedges include one file type, one team role, review before editing, or a plugin that proves live collaboration. Charge when the wedge completes a valuable job. Early revenue tests willingness to pay and reduces dependence on investor patience, though it may not finance deep infrastructure immediately.
Avoid building parity with mature desktop products before exposing the difference. Every familiar feature delays the moment customers can test the structural claim.
Worked example: Draftline Studio
Draftline plans a browser-based packaging design tool with simultaneous review. A simpler desktop application could reach paid beta in nine months. The browser architecture is estimated at 22 months.
The team of three costs £24,000 a month including salaries, contractors and infrastructure. The extra 13 months therefore cost:
13 x £24,000 = £312,000
Draftline has £470,000 of available runway. It also needs £110,000 for launch, security work and six months of post-release operation. The maximum pre-launch build budget is £470,000 - £110,000 = £360,000. The estimated architectural premium consumes 87% of that allowance.
The team creates a four-month vertical prototype costing 4 x £24,000 = £96,000. Twelve packaging teams test live review. Nine complete a review without exporting a PDF; seven use it for at least three projects; five sign conditional £350 monthly pilots if the tool imports their existing files reliably.
Potential pilot monthly revenue is 5 x £350 = £1,750, far below burn, but behaviour supports the mechanism. The team sets a continuation gate: import success above 95%, seven paid teams and median review time 30% below the existing process before spending the next £120,000.
It does not commit the entire 22-month forecast. It funds the structural bet in evidence stages. If users require extensive desktop features before live review helps, the browser advantage is not yet a viable wedge.
These figures are illustrative. Software cost, tax and compliance needs vary materially.
Keep architecture from becoming the message
Customers rarely buy WebGL, native code or a database choice. They buy the outcome that choice makes reliable. Position the observable difference and provide proof: a shared link, simultaneous editing, version recovery or access from managed devices.
Technical content can reassure expert buyers, but do not make non-technical customers translate architecture into value. Demonstrate the workflow with their files and constraints.
Also acknowledge trade-offs. Browser applications can face offline, performance, security-policy and device limitations. Desktop software can offer deeper local integration and predictable compute. A credible position says who benefits and who should choose something else.
Review the bet every six weeks
In the first week, define the blocked job, measurable customer cost and architectural mechanism. Build or isolate the hardest vertical slice, with a fixed cash ceiling.
Every six weeks, review technical minimums, repeated user behaviour, paid commitment and runway remaining. Authorise only the next evidence stage. Preserve launch and correction cash. If two reviews produce no movement on the same critical measure, narrow the workflow, change architecture or stop before technical pride consumes the company.
Related guides
Frequently asked questions
Is a browser app cheaper to build than desktop software?
Not automatically. A browser can simplify access and deployment, but sophisticated performance, offline behaviour, graphics, file handling and cross-browser support can be difficult. Desktop software may require separate operating-system work, installation and updates but can use local resources more directly. Cost the actual customer workflow, security requirements, supported environments and maintenance. Do not choose from a generic rule. Prototype the hardest requirement on target hardware, then compare the complete build and operating costs. Architecture should follow the valuable constraint, not an assumption about cheaper development.
How long is too long before launching software?
It is too long when the next period does not retire a named risk, runway no longer covers a sellable release, or users have not demonstrated the core behaviour. Calendar duration alone is insufficient. Deep infrastructure can require years, but it should produce staged prototypes and customer evidence. Set six- or eight-week gates for technical performance, usage and paid commitment. Protect post-launch cash. If the product needs every mature competitor feature before anyone can test its advantage, the initial scope is too broad even if the architecture is sound.
Should I build both browser and desktop versions?
Usually not at the start. Supporting both can divide a small team, duplicate testing and obscure which route creates value. Choose the architecture that best proves the primary job. A desktop wrapper or companion can come later if customers need offline access, operating-system integration or policy compliance. Do not promise parity before understanding the maintenance burden. Interview the first segment and document blockers. If half require desktop and half require browser, the segment may be too broad rather than the answer being two products.
Can technical architecture really be positioning?
Yes when it creates an experience customers can recognise and competitors cannot quickly reproduce. The positioning should express the outcome, such as shared editing through one link, not the underlying technology. Architecture becomes strategically meaningful when it changes adoption, collaboration, cost or risk. It is not positioning when customers neither notice nor care, or when a competitor can add the same outcome without changing its structure. Test customer behaviour and willingness to switch. Technical novelty alone is not a market position.
How do I test collaboration before the full product exists?
Build one shared workflow around a narrow file or object type. Ask real teams to complete an existing task simultaneously, including interruption, comments, permissions and recovery. Measure setup time, completion time, conflicts, return use and whether they retire the old hand-off for that task. Some surrounding work can be manual during the test, but the structural interaction itself must be real. Protect customer data and disclose limitations. A video demonstration can test interest, but only working use can test whether collaboration remains valuable under normal conditions.
What if users ask for ordinary features instead of the core difference?
Classify the request. Some features are table stakes required to experience the difference; others are habits from the old product. Build the smallest table-stakes set that lets the target workflow complete, then see whether users return for the structural benefit. Do not chase every parity request. If most qualified users refuse the product without years of conventional features, the chosen segment or wedge may be wrong. Narrow to customers whose blocked job is painful enough that they accept an initially limited tool.
When should I abandon the harder architecture?
Abandon or narrow it when critical performance remains below minimum after the allowed cycles, customers do not change behaviour, a simpler route delivers the same outcome, or runway cannot fund a safe release. Use a pre-declared gate rather than waiting for exhaustion. Preserve transferable components and user learning, but do not keep the architecture because it attracted investment or praise. Security or compliance barriers may also invalidate the first segment. Get qualified technical and legal advice before major migrations or customer-data changes.
Comments (0)