THE PROBLEM
A technically sound product concept, a founder with no design vocabulary, and a V1 demo that only worked in the happy path.
When the founder Srikar brought us in, he had a working V1 demo of the autonomous-fix loop and clear technical conviction about what the platform needed to do. What he did not have was a frame of reference for how a developer-tools SaaS site is structured, what a hero section is for, or how Python-first engineering teams evaluate a new tool in the first ten seconds of a landing-page visit. Before any UI could be designed, the engagement had to start one rung below design: with the anatomy of a SaaS landing page, the vocabulary of a developer-tools product site, and a reference library that would let a non-design founder compare and make informed decisions rather than vague ones.
The product UX had a structural failure mode that visual polish would never fix.
The V1 demo displayed exception attempts as a vertical list, with the Proposed Fix as a separate section at the bottom of the page. On a two-attempt example, the layout was functional. We asked the founder what would happen when the system made seventeen or eighteen attempts. The answer exposed the failure: a developer landing on an exception detail would scroll through a long list of failed attempts before discovering whether anything had worked, with the successful fix buried at the bottom and visually detached from the attempt that had produced it. This was not a layout problem. It was a product-logic problem that would get worse with every real-world exception that came through the system.
Developer trust in AI-proposed code changes is earned through the reasoning, not just the answer.
For a platform that autonomously modifies production code, the interface cannot simply show a diff and expect acceptance. Developers evaluating an AI-generated fix need to see the attempt chain, understand which attempt succeeded, inspect the exact call stack and variable state at the moment of the crash, and optionally test a candidate fix in a sandboxed environment before accepting the pull request. Designing surfaces that earned this level of trust meant treating each component of the exception detail as an information design problem with its own spatial grammar, not as a visual arrangement problem.
THE DESIGN JOURNEY
Information architecture before any UI, reference boards before any opinions.
We ran a complete site map and section-inventory pass before opening a design file. We walked Srikar through landing-page anatomy from first principles: what a hero section is, why it determines whether a visitor stays or leaves, and what each section down the page is responsible for. We proposed the nav structure (Landing, Blogs, Docs, Careers, Features with dropdown) and mapped the full section inventory (hero, stats, features explainer, how it works, core capabilities, integrations, pricing, FAQ, testimonials, footer). For every section, we delivered 15 to 16 reference boards showing layout variations from best-in-class developer-tool sites. The founder saw the full design space before any direction hardened, which made every subsequent decision faster and more confident.
Multiple hero explorations, a locked theme direction, and section-by-section UI built on a real foundation.
We ran a global direction exploration before any UI began: boxy with whitespace versus rounded and radius-heavy, dark versus light, gradient versus AI-generated backgrounds. Multiple variations per direction, founder-reviewed before any screen was built. With the aesthetic direction confirmed, we shipped the landing page: a centred heading-plus-description-plus-image layout in the classic dev-tool register, followed by core capabilities, the "see the system in action" flow, stats, feature cards, how-it-works sequence, and pricing with Free and Contact Founders tiers. The blog design included a citation-on-hover pattern: hovering any cited term in the body reveals the full source in a right-rail panel, giving the content a research-grade reading experience appropriate for an AI-native technical audience.
Product and coded prototype built simultaneously, with the design system delivered as running code.
While designing in Figma, we simultaneously built a working interactive prototype of the entire platform in Claude Code: the exceptions list, all three detail tabs, the Sandbox, integrations, billing, settings, four-step onboarding modal, Demo Mode, and all empty and populated states. This was not static mockups. It was a live, clickable experience with hover states, transitions, tab switching, and the full onboarding step-flow operating end-to-end. Srikar could click through every flow and give direct feedback on interactions rather than on frames. More importantly, the design system we built was already coded, so his production implementation became a lift-and-shift rather than a re-implementation. Per the founder, this delivered roughly a 10x acceleration on his build speed.
THE SOLUTION
An exceptions dashboard that balanced information density with immediate legibility.
After seven to eight layout explorations across side-by-side view, table, card, and Kanban formats, the final exceptions list used a table for density with KPI summary cards at the top: Total Occurrences, Unresolved, Auto Fixed, Average Fix Time, and New Today. Each row showed the exception type, file, repository, first-seen timestamp, and fix status as a colored pill: In Progress, PR Submitted, PR Merged, or Failed. Both the empty and populated states were fully designed. A Demo Mode badge in the top right allowed prospects to explore the full product experience without connecting a real repository, removing the biggest friction point in the developer-tools sales motion.
The Time Capsule tab composed call stack, code viewer, variables, session trail, and system snapshot into one coherent screen.
The Time Capsule is ThinkingSDK's term for the snapshot captured at the exact moment of a production exception. The left rail shows the call stack, the center shows the crashing function with the failing line highlighted, the right rail shows variables at crash time with type and annotation flags (for example, amount = -100, int, NEGATIVE), the bottom-left shows the chronological session trail leading to the crash, and the bottom-right shows system snapshot: Python version, platform, process memory, CPU load, thread count, and uptime. The design challenge was composing this depth into one screen without producing a monitoring-tool wall of dials. The answer was strict spatial grammar: each information type in a fixed, labeled region, each region with a single clearly defined purpose.
The four-step onboarding modal kept setup lightweight without ever interrupting the current page context.
A persistent "Set up ThinkingSDK, 1/4 steps completed" progress card in the sidebar opened the onboarding flow without navigating away from the current surface: step one connects GitHub by pasting a repo URL; step two installs the SDK with a copy-button code snippet; step three triggers a test exception; step four reviews the resulting pull request and opens it in GitHub. Each step had Skip, Back, and Next controls and a 1/4 through 4/4 dot progress indicator. The developer never lost their place in the product while working through setup, which matters for a tool that engineers evaluate by doing, not by reading.
THE KEY MOMENT
Inverting the attempt list so the successful fix surfaces first changed the product logic, not just the layout.
The V1 demo showed exception attempts as a top-to-bottom list with the Proposed Fix as a separate final section below. We asked what happens when there are seventeen attempts and the fix lands on attempt five. The developer scrolls past twelve failed attempts, then finds the fix at the bottom, visually separated from the attempt that produced it. Our proposal was structural: surface the successful attempt at the top of the list, with the Proposed Fix attached inline to the attempt that generated it, because the successful attempt is also the most recent attempt and the first thing a developer needs to find. This inversion sounds simple. Its consequences ran through the entire detail view. The attempt chain became a trust gradient from most recent downward, the fix became findable in under a second regardless of how many attempts preceded it, and the relationship between the fix and its generating attempt became visually explicit rather than implied. This is a reusable pattern for any multi-attempt AI surface: code generation, deep research, agent orchestration. Surface the answer first with the reasoning available below it, never the reasoning first with the answer at the bottom of a scroll.
The work, in detail.
The gallery below covers the ThinkingSDK landing page, blog with citation-on-hover pattern, exceptions list dashboard, exception detail across Overview, Time Capsule, and Sandbox tabs, integrations, billing, four-step onboarding, and Demo Mode in both empty and populated states.
Thinking SDK
industry:
B2B SaaS, AI
SCOPE:
Website
,
Product
duration:
3 Months
key outcome:
18 days
to ship MVP
