IST

Start a project

Web app development— dashboards, portals, SaaS front-ends

Dashboards, customer portals, SaaS front-ends and internal tools, designed around the one task people open them for. Typed, tested, documented and built to be handed over.

Start a projectSee the deliverables
010203040506
Part
CS-02 · Sheet 02 / 04
Deliverables
06 · handed over by operation
Tolerances
INP ≤ 200 msCLS ≤ 0.05LCP ≤ 2.0 sWCAG 2.2 AA
Stack
TypeScript · React · Astro islands · Tailwind CSS · Your stack

01Assembled from parts

Every screen, built from the same parts.

A dashboard is a set of components with a job each. Scroll to assemble one; hover a part to read its spec.

Wireframe · six components, one set of tokens · no real data

  1. C-01 Sidebar navigation
  2. C-02 Top bar and search
  3. C-03 Metric tile, used three times
  4. C-04 Line chart with a limit line
  5. C-05 Activity list
  6. C-06 Data table with status chips

02 · Fit

Who it's for.

  • ASeed to Series B product teams that need a senior design engineer without hiring a full team.
  • BTeams extending an existing app, or rescuing one that has become hard to change.
  • CFounders turning an internal tool or MVP into a product.

Problems this solves

  1. D-01The UI grew screen by screen and nothing matches.

    FixDesign tokens and a component library, so every screen is built from the same parts.

  2. D-02The key task takes too many clicks.

    FixA product spec and an interaction prototype you click through before production code.

  3. D-03Nobody wants to touch the front-end code.

    FixTypeScript, tests and architecture notes, so your team can change it with confidence.

  4. D-04Keyboard and screen-reader users are locked out.

    FixAn accessibility pass to WCAG 2.2 AA, checked against the spec.

03Routing sheet

What you get, operation by operation.

5 operations, in order. Each one hands over something you can check: 6 deliverables in total.

  1. Operation 10: Map the task

    Who opens the app, for what, and what 'done' looks like, written down as a product spec.

    Written notes, shared as you go

  2. Operation 20: Prototype

    The riskiest flow built first as a clickable prototype, so you react to real software.

    • 01Product spec and interaction prototype

  3. Operation 30: Components

    Design tokens and a component library: typed, documented and reused on every screen.

    • 02Component library and design tokens

  4. Operation 40: Build + integrate

    Screens, API integration, auth and roles, with a live staging link every week.

    • 03TypeScript front-end (React/Astro islands or your existing stack) with tests
    • 04API integration, auth and role handling

  5. Operation 50: Test + hand over

    Tests, an accessibility pass, architecture notes and a clean handover to your team.

    • 05Accessibility pass (WCAG 2.2 AA)
    • 06Architecture notes and a clean handover to your team

04Tolerances

The numbers this part ships inside.

Written into the spec before any design. Measured before handover, and dated in the report you keep.

Published budgets · 04 parameters · lab and manual checks
RefParameterToleranceInstrument
T-03INPInteraction to Next PaintMeasured on the interactions the spec names: menus, forms, filters, the checkout.≤200ms
T-02CLSCumulative Layout ShiftNo jumps from fonts, images or animation. Space is reserved before anything loads.≤0.05
T-01LCPLargest Contentful PaintLab run on the production build of every key template, dated in the handover report.≤2.0s
T-05WCAGAccessibilityAutomated checks plus a manual keyboard pass, tested against the spec before launch.2.2 AA
  • Contrast
  • Keyboard
  • Focus
  • Labels
  • Reduced motion

06Questions

Web apps & platforms: answers.

Short and factual. Anything else, just ask us.

04 questions · answered by the studio

Q.01Can you work in our existing stack?

Yes. Existing stacks are fine for web app work. New front-ends are typically TypeScript with React or Astro islands, with tests.

Q.02Do you build the backend too?

The focus is the front-end: UI, API integration, auth and role handling. When a project needs backend work, we bring in a backend engineer we've worked with before, and you'll know their name and role from day one.

Q.03Will our team be able to maintain it?

Yes. The code is typed and tested, the component library is documented, and handover includes architecture notes. You own all code and accounts.

Q.04How long does a web app phase take?

[Founder to confirm] Web app phases typically take 8 to 16 weeks. The written spec fixes scope and timeline before work starts.

07 · Work order

Open a work order.

Pick the part and the way you'd like to work. Your brief opens with both filled in, and we reply within one working day.

Order slipWO · CS-02 × EM-01
01 · Part
02 · Engagement model

Web apps & platforms, as a fixed-scope project.

Start this brief