Karan Singh
Services

What we build, and how we'd work

Five shapes of work, three ways to buy it, and the process in between. If your project doesn't fit neatly into any of these, say so on the call — it usually still does.

From scratch

New applications

An idea with nothing built yet. We take it from the first conversation to something real people can use — no hand-off gaps between front end, back end and database for bugs to hide in.

  • React components wired to REST APIs you own
  • Spring Boot services, persistence and schema design
  • Role-based access separating admin and user surfaces
  • Deployed, tested and documented before handover
Extend

Existing systems

Something already runs and needs to do more. Features, upgrades and refactoring added without destabilising what your users depend on today.

  • New features inside an existing codebase
  • Java version upgrades and dependency migrations
  • Test coverage around what we touch
  • We follow your conventions rather than importing ours
Connect

Integrations and data pipelines

Getting your system to talk to someone else's — the work that always overruns, because the other side's spec is wrong and nobody tells you until you build it.

  • REST integrations against third-party systems
  • SFTP and file-based enterprise exchange
  • Kafka event pipelines with idempotent consumers
  • Retry, backoff and failure handling that works
Restructure

Monolith to microservices

Incremental extraction, not a big-bang rewrite. On our last e-commerce migration this cut response time by 31% with no feature freeze.

  • Service boundaries mapped before code moves
  • Integration testing across the new seams
  • Zero-downtime database migrations
  • A rollback path at every step
Rescue

Performance and debugging

Slow endpoints, memory climbing until a restart, throughput collapsing under load. We measure first and show you the code path responsible — with evidence, not a guess.

  • YourKit and JMeter profiling under real load
  • Heap dump analysis for leaks and OOM crashes
  • Thread contention and deadlock hunting
  • A written report ranked by impact and effort
Diagnosis

How we find what's actually wrong

When something is slow, most teams guess. This is a flame graph — a profiler's picture of where a request spends its time. Read it upward: the base is the request, each row is one level deeper into the stack.

Flame graph — checkout request, 30s sample width = time spent

The wide red frame at the top is a lock 28% of the request is spent waiting on — not the database everyone blamed. Twenty minutes with a profiler beats two weeks of rewriting the wrong thing.

Architecture

How we put a system together

The shape we reach for when a service has to stay responsive while something behind it is slow — and, on the bottom rail, the measurement layer that tells you which.

Reference backend architecture A React application and partner systems reach an API gateway with authentication and rate limiting, which routes to Spring Boot microservices. Services exchange events over Kafka, and persist to MySQL via Hibernate and JPA. A measurement layer of profiling, heap analysis, early warning monitoring and CI gates spans the whole system. CLIENTS EDGE SERVICES · SPRING BOOT MESSAGING STATE & EXCHANGE React app COMPONENTS · REST / JSON Internal systems REST · SCHEDULED Vendor systems SFTP · UIV · FILES API gateway AUTH · ROLE-BASED RATE LIMITING REQUEST VALIDATION Domain service MVC · SPRING BOOT Processing service MULTI-THREADED · POOLED Integration service ADAPTERS · RETRY / BACKOFF Kafka TOPICS PARTITIONED BY ENTITY KEY CONSUMER GROUPS IDEMPOTENT REPLAY-SAFE MySQL SYSTEM OF RECORD Hibernate / JPA TUNED ORM LAYER SFTP exchange BATCH · VENDOR FILES External REST THIRD-PARTY SYSTEMS Measurement layer — the part that tells you where the time goes YOURKIT PROFILING · HEAP DUMP ANALYSIS · JMETER LOAD TESTS · EARLY WARNING SYSTEM · SONARQUBE GATES · JENKINS CI/CD

Most teams build the top four columns and skip the bottom rail. Then nobody can say why the service got slow. We build the rail first — it's how the 31% was found, and how we knew it was real.

Engagement

Three ways to work with us

Pick whichever matches how well-defined the work is. If you're not sure yet, start with a call and we'll work it out together.

Fixed scope

Audit & roadmap

For teams deciding whether to rebuild, scale or hire — or whose system is misbehaving and nobody knows why.

  • Codebase and infrastructure walkthrough
  • Profiling under realistic load where relevant
  • Written report, findings ranked by impact
  • Walkthrough session with your engineers

1–2 weeks · Fixed fee

Ongoing

Monthly retainer

For teams needing reliable development capacity without another full-time hire.

  • Reserved hours each week, agreed ahead
  • Feature work, code review and escalations
  • Direct Slack access during agreed hours
  • Rolling monthly, thirty days' notice either way

Minimum 2 months · Monthly rate

Rates depend on scope, urgency and domain. We'll quote a number on the call rather than making you guess from a pricing table.

Process

How a project actually runs

Four steps, in this order. You can stop after step two if the scoping document tells you the work isn't worth doing — that outcome is a win for you, and we'd rather say it early.

STEP 01

Discovery call

Thirty minutes. You describe what you want — or what's going wrong — and we ask the awkward questions about users, data, deadlines and who else touches the code.

FREE · SAME WEEK
STEP 02

Scope and estimate

A written document: what gets built, what explicitly does not, the technical approach, milestones, and a fixed price or rate. You own it either way.

2–4 DAYS
STEP 03

Build in visible slices

Code in your repository from day one, a demo each week against a real environment, and a short written update every Friday. No month-long silences.

ONGOING
STEP 04

Handover and support

Documentation, a runbook, an architecture walkthrough with your team, and thirty days of bug-fix support after the final milestone.

+30 DAYS INCLUDED
No pitch deck, no obligation

Start with a conversation.

Bring the project in whatever shape it's in. A rough idea, a half-finished codebase, or a production problem you can't reproduce — all perfectly good starting points.