I made an extension to solve my own problem.
FIG 01 — QuickLinks Chrome Extension Interface.
The internship grind and the repetitive form.
Lately I was applying to a lot of internships. I noticed a steady, repetitive pattern: the application form was always consistent, asking for the exact same inputs. The problem was, on many sites, I didn't want to use my Google Account to log in, but I still wanted to submit the form really quickly.
One of the main places I constantly got stuck was identity data. Every distinct form required me to input my LinkedIn, my portfolio, my Instagram, my social media handles, and various emails. It was incredibly tedious. I realized: how can I solve problems for others as a designer if I don't solve a problem I am actively facing?
Three clicks is three too many.
So I made an extension. Version 1 was essentially a digital notepad that just saved all my links in it. It held my work email, personal email, Behance, Contra, LinkedIn, Twitter, everything. I could add, edit, or remove URLs easily. I started using it for my applications.
But I soon realized I had created a new problem. There were still three clicks happening:
1 Clicking the browser extension tab.2 Finding the specific QuickLinks extension.3 Copying the exact link I needed (e.g., LinkedIn).
As easy as it sounds, for a user doing a highly repetitive task, three clicks is annoying. I had to solve for time. I had to solve for clicks.
FIG 02 — The V1 Command Center approach still required manual invocation.
Reading the code like a human being.
The next step was obvious: make an extension that is always active on a website. It basically works by reading the code on the web page you currently have open. It locates the inputs.
But how a human being identifies an input is very specific. A human identifies an input by looking at the label above it, or the placeholder text inside it. My extension determines what the input is exactly the same way—by reading the `label` and the `placeholder`. By doing this, it accurately determines if it's a LinkedIn field, an email, a username, Twitter, Instagram, or Behance.
FIG 03 — Suggestion chips hovering over inputs on a live site, triggered by context.
The "Name" Workaround and Contextual Injects.
Contextual Prompting
What happens next is it suggests based purely on the type of input it found. If it's an email field, it suggests the work email and primary email I saved. If it's Behance, it exclusively suggests my Behance URL.
The Username Workaround
The name detection is actually a bit of a clever workaround. Often, you don't save just your "first name" in a digital notepad. But QuickLinks takes whatever email you try to put in (personal or work), drops the domain, and converts it into a username based on `first.last@...` patterns, smartly suggesting "First Last" into name inputs.
Extreme Edge-Case Testing.
Because swipe coding and robust software architecture are critical in 2026, I didn't just code the happy path. I built a comprehensive testing laboratory to simulate how broken and inconsistent the open web actually is.
FIG 04 — The custom HTML testing laboratory simulating generic forms and SPAs.
FIG 05 — Advanced testing for delays, modals, and rapid tab-focus race conditions.
Email Detection Types
Tested 6 different types of standard and non-standard email inputs. Some had labels, some were placeholder only, some just said `dash@domain.com` inside the placeholder.
Simulated Real-World Forms
Ran submissions mimicking Job Applications (first, last, phone, linkedin, portfolio), newsletter signups, freelance profiles, and contact forms.
Ambiguous Edge Cases
Handled tricky inputs that didn't really mention intent in the placeholder, disabled inputs (which should NOT trigger), and read-only sections.
Dynamic SPA Simulations
What if you click a button and a form is fetched from a server later? The extension actively leverages MutationObservers to look for code changes. Modals that take 3 seconds to load? Handled.
Negative Testing
It was crucial that it shouldn't trigger everywhere to avoid annoying the user. It ignores passwords, search bars, quantities, date of births, company names, and zip codes.
“You can't design a friction-less experience for others if you tolerate friction in your own digital life.”
From a product designer's perspective, QuickLinks was an exercise in extreme constraint. It proved that sometimes the best UI is literally invisible—reading the page, acting like a human, and stepping out of the way before the user even realizes they saved 15 seconds.