Designing a B2B CRM, then leading the team that ships it.

Keep spec, UI, and implementation in one short loop.

co-nect is a Japanese B2B SaaS startup. I joined to help build a new CRM tool from the ground up — a product whose success criterion was not "be flashy" but "feel right under daily, repetitive use." Early on, the team needed someone who could span spec, UI design, and front-end as one role, with the expectation that the role would evolve post-launch.

Remove friction from an interface people return to every day.

• No room for centralized design hours. Spec, UI, and front-end had to live in one head, or the loop would outrun what the team could absorb.
• Daily-use UI is unforgiving. Friction that survives one sprint compounds into thousands of micro-frustrations.
• The role had to flex post-launch. The shape that worked at zero-to-one was not the shape that works at growth.

Choose a shippable foundation and shorten decisions.

The project ran in two distinct modes: build-mode (spec to ship) and growth-mode (post-launch direction). The role in each was deliberately different.

Used MUI + Storybook as a shared baseline

Custom-designing every primitive would have been a luxury. MUI gave us a credible default, and Storybook became the single source of truth for designers and engineers. Figma → Storybook → product became a tight loop with little drift.

Owned the spec → UI → front-end loop solo, early on

In the first year I held all three steps. Owning every link meant decisions were tested against implementation reality immediately — no week-long round-trip between roles. The shape worked because the team was small and the surface was new.

Shifted into requirements + engineering lead post-launch

Once live, the bottleneck moved from "make the UI" to "decide what to build next, and how." I moved into requirements definition and engineering team management — running spec sessions, prioritizing, reviewing implementation. The design quality bar carried forward through reviews rather than my own hands.

After launch, move from making the product to moving the team.

• The spec → UI → code loop stayed tight while the product was finding its shape.
• Post-launch quality held through reviews and structured requirements, not centralized design hours.
• The role flexed with the phase — a deliberate move, not an org-chart accident.

When the phase changes, the valuable work changes too.

At zero-to-one, the most useful move was shortening the distance between spec, UI, and implementation. After launch, the more durable work was helping the team keep making decisions from the same baseline. That is why the role moved toward reviews, requirements, and prioritization. Design quality lasted longer as a team decision pattern than as my own output volume.