We shipped a 417 kilobyte image as a 16 pixel icon, three times
Version 0.1 of the extension lived for three days. Version 1 was built in thirty-two minutes and included a stage numbered 1.5, inserted after stage 2.
The first version of the Chrome extension shipped on 2026-05-06 at 01:49, in a single commit, at 630 lines. It put an "Add to DealArena" button on LinkedIn, Sales Navigator, and two data platforms, and it authenticated with a token you pasted in by hand.
It also shipped with three icons. Chrome asks for a 16 pixel one for the toolbar, a 48 for the extensions menu, and a 128 for the store listing. We supplied all three.
All three were the same file. That file was the site logo, at 417,301 bytes.
I went back and checked this while writing, because it seemed too good to be true, and the git object hash is identical across all three entries and identical to logo.png committed back on 2026-02-02. So the extension shipped with 1.25 megabytes of icons, in a 630-line extension, and the operating system dutifully scaled a 417 kilobyte image down to sixteen pixels square every time it drew the toolbar.
In the same commit, options.html is four lines long.
Version 0.1 lived for three days
On 2026-05-09, between 02:17 and 02:49, version 1 was built. Seven commits, thirty-two minutes.
Stage 1 laid a backend foundation, at 2,876 lines. Stage 2 is described in its subject as a "refactor," which undersells it considerably: it deletes background.js and content.js, which are the two files that constituted version 0.1, and replaces them with a proper source tree. A service worker, an API client, a shared content module, six per-site extractors, three entry points, and four user interface modules. Two more arrive at Stage 4.
Version 0.1 was seventy-two hours old. It was not extended. It was deleted and rewritten by the same person who wrote it.
I think that is the correct call and I want to defend it, because "rewrite it three days later" is the kind of thing that sounds like waste. The first version answered one question: can we reliably pull a person's details off a LinkedIn profile and get them into the CRM in one click. That is a genuine unknown, and 630 lines was a cheap way to find out. Once the answer was yes, almost none of that code was worth keeping, because the second question is completely different: how do we do this on six sites that all change their markup whenever they feel like it. Six small extractors behind one interface is the answer to the second question. It is not an improvement on the first version. It is a different program.
The nice detail is Stage 1.5. It lands at 02:35, between Stage 2 and Stage 3, and adds cost tracking and credit infrastructure. Somebody got two stages into a six-stage plan, realised the plan was missing a foundation, went back, wedged it in with a decimal point, and carried on. The numbering is a retrofit happening in real time, preserved in the log.
You can tell a lot about how a build actually went by whether the plan has fractions in it.
The icon saga has three acts
The 417 kilobyte icons died at 01:15 on 2026-05-09, about an hour before version 1 was built, and their death was an accident.
A rebrand commit landed at that minute, sweeping across seventy files to move the whole product from a neon green hacker theme to orange. It regenerated favicons as a side effect, and the extension icons came along for the ride. They dropped from 417,301 bytes to 472, 1,019, and 2,059 bytes respectively. Nobody was thinking about the extension. The icons were fixed by proximity.
Except they were fixed to the wrong thing. Version 1 went out at 02:45 with store listing preparation complete: a listing document, a privacy policy, a screenshots directory. And a placeholder logo, reading "DA," still sitting in the icons.
That was not caught until 19:10 the same day. Sixteen hours of a finished, store-ready extension carrying a placeholder mark. The commit that fixes it is titled "swap 'DA' placeholder for the bracket-arrow mark," and it does one other thing that matters more: it adds a 66-line script that generates the icon set from a source image.
That script is the actual fix. The icons had now been wrong twice, in two entirely different ways, and both times the failure was that a human was expected to remember to resize an image correctly. The third version of an icon is where you stop producing icons by hand.
What the drawer actually does
The visible feature, once all of this settled, is a drawer that appears on a LinkedIn profile with everything the CRM knows about that person, and a button that adds them if it does not know them yet.
That sounds small. It removes a specific and awful bit of friction: the moment where you find someone worth talking to, and adding them to your pipeline means leaving the page, finding the right screen, retyping a name you can see on the other tab, and losing the thread of whatever you were doing. Every seller has, at some point, decided a prospect was not worth the twelve seconds. The extension exists so that decision never gets made.
The persistent surfaces from Stage 4 push it further. A badge that marks people you already have, on the page, before you click anything, so you stop opening profiles you have already worked.
Both versions of the extension were built between one and three in the morning, three days apart, which is consistent with the rest of this project's history and slightly worrying as a pattern. The store submission, for what it is worth, did not actually happen for another two and a half months, and when we finally went to file it we discovered the manifest could not be loaded at all. That is a story for a later entry.
The icons, at least, have been fine ever since. A script does them.
— DealArena Team