How I work

Enterprise products, built step by step

Design systems, enterprise web applications, Flutter mobile apps and microservices — delivered as one coherent platform rather than four disconnected projects. Below is the actual process: what happens at each stage, what you receive, how long it takes, and the gate that has to pass before we move on.

Start a project See the 7-step process NDA before we talk

7+ years

shipping production software

Bi-weekly

staging milestones you can see

GMT+6

EU morning + US morning overlap

Written scope

before any code is written

One request, end to end

  1. 1

    Flutter / Web apps

    Client experience

  2. 2

    API gateway

    Auth, rate limits, contracts

  3. 3

    Capability services

    Independently deployable

  4. 4

    Data and events

    Postgres · Redis · queues

What I build for enterprise teams

Four disciplines that have to fit together. Each one is a working part of the same delivery process below — never a separate hand-off between teams who never speak.

Design systems

One design language, coded once and enforced by CI.

A design system is the difference between a product that can be extended for years and one that gets rebuilt every three.

What you get

  • Design tokens (colour, type scale, spacing, elevation, motion) as the single source of truth
  • Component library with documented states, edge cases and accessibility behaviour
  • Figma library and code kept in parity, so hand-off stops being a translation exercise
  • Versioned package published to your registry — teams upgrade on their own schedule
  • Storybook-style playground, usage docs and migration notes
  • CI gates: visual regression, axe accessibility checks and token linting
Discuss this work

Enterprise web applications

Multi-tenant business software that survives audit and scale.

Internal platforms, customer portals and operational tooling where permissions, traceability and uptime actually matter.

What you get

  • RBAC and SSO (SAML/OIDC), tenant isolation and audit trails on every privileged action
  • Complex data-dense UI: virtualised tables, filters, bulk operations, saved views, exports
  • Integrations with the systems you already run — ERP, CRM, HRIS, billing, calendars
  • Billing and entitlement flows (Stripe) including trials, proration and dunning
  • Internationalisation, accessibility and role-specific onboarding
  • Reporting, scheduled exports and document generation where the business needs paper
Discuss this work

Flutter mobile apps

One codebase, two stores, field-ready behaviour.

Enterprise mobile work is mostly about what happens when the network, the battery or the device lies to you.

What you get

  • Offline-first data layer with conflict resolution and background sync queues
  • Secure storage for tokens and biometric unlock; no secrets in the binary
  • Push notifications, deep links and app-to-app hand-off that actually resolve
  • Camera, barcode, file and location capture with retry-safe uploads
  • Release pipeline to TestFlight and Play internal tracks, with staged rollouts
  • Crash reporting, analytics and a crash-free-session target agreed up front
Discuss this work

Microservices & platform engineering

Deployable independently, observable by default.

Services split along business capabilities — not along file names — so teams stop blocking each other.

What you get

  • Bounded contexts and a written service map before a single service is created
  • Contract-first APIs (OpenAPI): generated clients, versioning policy, contract tests
  • Gateway, authentication and rate limiting at the edge; least-privilege service credentials
  • Event-driven integration where it earns its keep, with idempotency and dead-letter handling
  • PostgreSQL/MongoDB modelling, Redis caching, migrations that are safe to roll back
  • CI/CD with blue-green or canary deploys, plus logs, metrics, traces and health checks
Discuss this work

The process

Seven stages, each with an exit gate

The rail fills as you scroll. Every stage lists the artefacts you receive and the condition that must be true before the next stage starts — so progress is provable rather than a matter of opinion.

  1. AlignWeek 1

    Discovery and alignment

    Understand the business outcome before proposing any technology. Nothing is built on assumptions.

    What you receive

    • Written scope: what is in, what is explicitly out
    • Success metrics we will be judged on at handover
    • Risk register and constraint list (compliance, legacy, deadlines)
    • Environment, access and NDA requirements confirmed

    Exit gate: Signed statement of work, one named decision-maker, all environments identified

  2. Design the systemWeeks 2–3

    Architecture and foundations

    Decide the shape of the system on paper where changes are cheap, then make the decisions reviewable.

    What you receive

    • System context and container diagrams, plus the service map
    • Architecture decision records (ADRs) for every choice we cannot easily reverse
    • Design tokens and a component inventory covering the first release
    • Repository structure, environments (dev/stage/prod) and a working CI pipeline

    Exit gate: Architecture walkthrough approved by your technical stakeholders

  3. Build the vocabularyWeeks 2–5, in parallel

    Design system in production

    Ship the design system as real code with tests and documentation — not a Figma file that never matches production.

    What you receive

    • Component library with every state documented: loading, empty, error, permission-denied
    • Accessibility behaviour built in (focus management, ARIA, keyboard paths)
    • Versioned package published to your registry, with migration notes
    • CI gates: visual regression, axe accessibility checks and token linting

    Exit gate: First screens composed from library primitives — no ad-hoc colours or one-off spacing

  4. Prove it end to endWeeks 4–6

    First vertical slice

    Prove one real feature through every layer before scaling the pattern across the platform. This is where most risk is retired.

    What you receive

    • One complete feature: UI → API → service → database, deployed to staging
    • Automated tests on the critical path, running in CI
    • Observability wired up: structured logs, metrics, error tracking
    • Performance baseline captured for later comparison

    Exit gate: Live demo on staging with real data, and a rollback that has actually been exercised

  5. Scale what worksWeeks 6–14

    Services and mobile scale-out

    Turn the proven slice into independently deployable services and store-ready mobile apps, so teams can ship without waiting for each other.

    What you receive

    • Services split along business capabilities, each with its own contract and pipeline
    • Gateway, authentication, rate limiting and least-privilege service credentials
    • Offline-first Flutter app: sync engine, conflict handling, retry-safe background uploads
    • TestFlight and Play internal-track builds produced by CI, with staged rollouts

    Exit gate: Contract tests green across services, load test at target concurrency, crash-free sessions ≥ 99.5%

  6. Make it defensibleWeeks 12–18

    Security, compliance and performance

    A platform that fails safely, recovers quickly and can be evidenced in an audit rather than described in a slide.

    What you receive

    • Security review fixes, dependency and secret scanning, OWASP checks on every new endpoint
    • Backups plus a restore drill you have watched succeed
    • Performance budgets enforced in CI (API p95, payload size, LCP)
    • Runbooks: on-call, incident response, rollback, data retention

    Exit gate: Restore drill passed, p95 budgets met, all findings closed or explicitly accepted in writing

  7. Leave you in controlWeeks 18–20+

    Release, handover and support

    Your team owns the system confidently, including the parts they did not write.

    What you receive

    • Production cutover plan with rollback and feature-flag rollout
    • Documentation: ADRs, repository READMEs, API contracts, changelog
    • Recorded handover sessions with your engineers and product team
    • 30-day hypercare at an agreed response time, then an optional retainer

    Exit gate: Production release, handover delivered, support window agreed in writing

On durations: the weeks shown are typical for a platform build and move with scope, team size and how quickly decisions are made on your side. The dates that matter are the ones written into the statement of work.

Working together

The weekly rhythm

You should never have to ask what is happening. The cadence below is the same on a two-week audit and a six-month platform build.

Monday

Written weekly plan

What ships this week, what is at risk, and the decisions I need from you. Sent before your week starts.

Every day

Async stand-up

Three lines in your Slack or Teams: finished, next, blocked. No meeting required to stay informed.

Wednesday

Staging demo

Fifteen minutes on a working build with real data. Recorded when you cannot attend, never replaced by a status email.

Friday

Written status and invoice

Shipped, in progress, risks, decisions taken, hours or milestone billed. One page, same format every week.

Continuously

Your tools, your records

Repositories, tickets and documentation live in your accounts. Nothing of value exists only in my head or my laptop.

Definition of done

What “done” means here

Eight gates every increment has to clear. They are enforced in CI where possible, so “done” does not depend on who is reviewing that day.

Automated tests

Unit and integration tests on logic, E2E on the two or three paths that would hurt most if they broke.

Typed boundaries and lint clean

TypeScript on the web, strong typing across API boundaries, lint and CI green before review.

Accessibility

Automated axe checks plus a keyboard-only pass. WCAG 2.2 AA for new UI, with focus order verified.

Performance budgets

API p95, bundle size and LCP tracked in CI. Regressions fail the build instead of being discovered by users.

Security

Secrets in a vault, least-privilege access, dependency and secret scanning, OWASP checks on new endpoints.

Observability

Structured logs, metrics, traces, health checks and error tracking wired up before release, not after an incident.

Documentation

ADRs for the significant decisions, repository READMEs, API contracts and a changelog a new joiner can follow.

Reversibility

Feature flags and rollback-safe migrations, so shipping on a Friday is a boring event.

Engagement shapes

Four ways to start

Most enterprise work starts with an audit or a design-system-first build, then grows into a platform programme or a retainer once we both know the codebase.

1–2 weeks

Architecture audit

You need an outside read before committing budget.

  • Current-state review of code, infrastructure and delivery process
  • Findings ranked by business risk, not by personal taste
  • Target architecture and a sequenced roadmap
  • Written handover session with your team
6–10 weeks

Design system + first slice

A product that needs a durable UI foundation and one shipped feature.

  • Design tokens and a documented component library
  • One complete vertical feature in production
  • CI with visual, accessibility and performance gates
  • Playbook so your team extends it without me
12–24 weeks, phased

Platform build

New enterprise product, or a legacy platform being replaced.

  • Web application, services and mobile app delivered in phases
  • Milestone demos every two weeks on staging
  • Security, performance and observability hardening
  • Handover and hypercare, then optional retainer
Monthly

Retainer / fractional lead

Existing team that needs senior architecture ownership.

  • Architecture and code review cadence
  • Design-system stewardship and standards
  • Hiring support and technical interviews
  • Release and incident guidance
On pricing: engagements are scoped and priced after discovery, because a number invented before the scope exists is not a number you can plan with. The enquiry form collects an indicative budget range, and billing terms live in section 4 of the Terms of Service.

Tooling

The stack I bring, and the one you already run

I join the stack you have where it is sound, and argue for changes only where they buy something concrete. Everything listed below has been used on real client work.

Front end

  • React
  • TypeScript
  • Next.js
  • Tailwind CSS
  • Flutter / Dart
  • Storybook
  • Framer Motion

Backend

  • Node.js / NestJS
  • Express
  • Spring Boot
  • Django / Python
  • REST / OpenAPI
  • GraphQL
  • WebSockets

Data

  • PostgreSQL
  • MongoDB
  • Redis
  • Kafka / RabbitMQ
  • Aggregation pipelines
  • Migrations

Platform

  • Docker
  • Kubernetes
  • Nginx / PM2
  • GitHub Actions
  • AWS / Render / Vercel
  • Sentry
  • Stripe
  • k6 / Playwright / Cypress

Questions enterprises ask

Before you send the brief

The eight questions that come up in almost every procurement conversation, answered the way I would answer them on the call.

Then we audit it rather than replace it. I start by mapping what exists against real screens, finding the gaps that force people to hand-roll UI, and fixing those first. The usual outcome is a smaller token set, better component coverage for edge states, and CI gates that stop drift — with your designers still owning the language.

Start with a 30-minute discovery call

Bring the thing that is worrying you — a deadline, a legacy platform, a design system nobody uses, an app that fails in the field. You will get a straight answer about fit and the engagement model that makes sense, usually within one business day.

Start a project turjo_t@yahoo.com
  • Mutual NDA within one to two business days — how NDA works
  • Vendor security questionnaire and scope document on request
  • Response within one business day, in your timezone window
  • Everything else a legal team asks for is on the policies and documents page