Services
Find your situation. Then read what I'd do.
Most people arrive here with a symptom rather than a specification. Start from the line that sounds like your situation. Each one leads to how I'd take it on and what you end up holding.
Sounds like you?
01
You have a product to build and no engineering team to build it.
02
The product works, but nobody can safely change it any more.
03
The interface is slow, or the frontend has become the bottleneck.
04
The services behind the product are slow, or they fall over when traffic climbs.
05
You need someone accountable for technical direction, not more code.
06
You want AI in your engineering process without lowering the bar.
07
You need the interface designed, not just built.
01
You have a product to build and no engineering team to build it.
Product build, end to end
Founders · product teams without in-house engineering
I take a product from an idea and a set of constraints to something running in production that real users can reach. One person accountable for the architecture, the interface and the infrastructure, which for a first version is usually faster than assembling a team.
What I do
- Turn the product idea into a technical plan: scope, architecture, stack, sequence.
- Break each requested feature into sub-features, developed on their own iterative lifecycle.
- Build the frontend, the backend and the deployment path.
- Hand off analysis, requirements, software design diagrams, code and manual test reports for every sub-feature.
- Format those diagrams to whatever standard you work to, such as ISO or IEEE.
You get
- A running product in production, on infrastructure you own.
- The codebase, with the architecture written down.
- Analysis, requirements, design diagrams and manual test reports for every sub-feature delivered.
- Daily progress reports, with the related documents attached.
- A prioritised list of what I would build next and why.
Engagement
Each requested feature is divided into sub-features, and every sub-feature runs through its own iterative development lifecycle under the Millwright-Inspector Methodology I created. A sub-feature is completed in at most one day, with progress reported daily alongside its documents.
Behind it
Pegasus Airlines and Zeplin.io: large-scale production systems delivered against real users and real release constraints.
02
The product works, but nobody can safely change it any more.
Rescue and modernization
Teams with a production system that has outgrown its original design
Software that has been shipping for years accumulates decisions nobody remembers making. I work inside systems like that: understand what is actually there, find where the risk sits, and change it incrementally while it stays in service. No rewrite proposals unless a rewrite is genuinely the cheaper option.
What I do
- Read the system as it is, including code, data, deploy path and the parts nobody touches, then write down what I find.
- Identify the changes that reduce risk fastest, in order.
- Introduce types, tests and observability so the next change is safer than the last.
- Refactor and migrate in increments that ship, never a stop-the-world rewrite.
You get
- A written assessment of the system: what is fragile, what it costs you, what I would do about it.
- The highest-value changes actually implemented, not just recommended.
- A migration path your own team can continue without me.
Engagement
Starts with an assessment, priced separately, which stands on its own if you take it no further. Implementation follows in increments once we agree the order of work.
Behind it
Heinrich Schmid: 40+ services, 11 frontends, 45+ shared libraries, changed continuously while live.
03
The interface is slow, or the frontend has become the bottleneck.
Frontend architecture and performance
Product teams whose frontend has grown past its original structure
Frontend at scale is an architecture problem long before it is a framework problem. Seventeen years across product, enterprise and consulting work, covering a mature SaaS application, a microfrontend estate of eleven apps and banking and airline platforms, taught me where the real costs are: rendering, state, bundle boundaries, and the shared code everybody depends on.
What I do
- Profile what is actually slow, rather than what looks slow, and fix in order of measured impact.
- Improve SEO performance and page rendering speed, first load included.
- Restructure the frontend architecture: state, component boundaries and re-render cascades.
- Optimize how the frontend and backend interact: payloads, round trips and caching.
- Split bundles, introduce lazy loading, and cut what ships to the browser.
- Modernize the existing system with current technologies, in shippable steps.
- Point out and fix potential security problems in the frontend.
- Set the structure for shared libraries and design-system code across multiple applications.
You get
- Measured improvements, with before and after numbers.
- A written report on every problem found, with alternative solutions and the one I would choose.
- A frontend structure the team can extend without fighting it.
- Security issues identified and fixed, with what changed written down.
- The profiling method, so the next regression is caught by you.
Engagement
Starts by analysing the existing architecture and reporting on what to improve, with a total estimation and the reasoning behind it, argued from Human-Computer Interaction theory and UX/VD design rather than preference. Work then proceeds in increments, in the order the report justifies.
Behind it
Rebranding Zeplin.io and Pegasus Airlines; migrating İşWeb from vanilla JavaScript to Angular.
04
The services behind the product are slow, or they fall over when traffic climbs.
Backend performance and scalability
Teams running APIs and services under real load · regulated and high-traffic platforms
Most backend slowness is not a hardware problem. It is queries that were fine at a tenth of the volume, services that talk to each other more than they need to, and no measurement to prove either. I work on systems where downtime is visible to customers, including banking and airline platforms, a forty-service estate and time-series ingestion, and I fix in the order the measurements justify.
What I do
- Trace the slow paths under realistic load and find where the time is actually spent.
- Optimize the architecture itself, not only the code inside it.
- Fix queries, indexes and data access before adding infrastructure to the problem.
- Reduce chatter between services, and cache only where it is safe to cache.
- Cut cloud cost where the same work can be done on less.
- Add capability where it pays: AI agent integration, RAG systems, Elastic Search and cache layers.
- Build custom interfaces and dashboards so the people running the system can see it.
- Set out every problem found in a structured document, with alternative solutions and fix items.
You get
- Measured improvements, with before and after numbers under load you recognise.
- A structured document of the problems found, each with alternative solutions and a recommended fix.
- Custom dashboards and alerts your own team owns and understands.
Engagement
Starts with a measurement and tracing pass, so the work is driven by data rather than intuition, then proceeds in increments ordered by measured cost.
Behind it
Banking and airline platforms serving millions of users; 40+ backend services at Heinrich Schmid; time-series ingestion, Redis caching and RAG systems for Kemisan.
05
You need someone accountable for technical direction, not more code.
Technical leadership and advisory
Teams without a senior technical voice · non-technical founders
Sometimes the constraint is not delivery capacity but the absence of someone who can make architecture calls and defend them. I take that role: choosing technology, sequencing work, reviewing what gets built, and telling you plainly when a plan will not survive contact with production.
What I do
- Make and document architecture and technology decisions, with the trade-offs written down.
- Review code and designs, and set the standard the team works to.
- Estimate and sequence work, and report risk before it becomes a delay.
- Coach engineers, so the capability stays after the engagement ends.
You get
- Decisions recorded with their reasoning, not just their outcome.
- A delivery plan you can hold people to.
- A team that is measurably more senior than when I arrived.
Engagement
Ongoing and part-time, sized to your delivery rhythm, with enough continuity for decisions to land and be seen through.
Behind it
Technical lead on the Pegasus Airlines web application: estimation, technology selection, CI testing and guidance for junior engineers.
06
You want AI in your engineering process without lowering the bar.
AI-assisted engineering, done properly
Engineering teams evaluating agent-assisted development
Coding agents produce plausible code quickly, which is exactly the problem. I build the workflow around them: explicit contracts, verification gates and review steps that keep generated code honest, so the speed is real rather than borrowed from your future maintenance budget.
What I do
- Set up agent workflows with explicit contracts and verification gates.
- Define where generation is allowed and where a human decision is mandatory.
- Build the review and testing steps that catch plausible-but-wrong output.
- Train the team on the method, not just the tools.
You get
- A documented working method your team can actually follow.
- Tooling and prompts configured for your codebase.
- An honest assessment of where AI helps you and where it does not.
Engagement
An engagement to establish the method, with optional follow-up as the team adopts it.
Behind it
Millwright-Inspector: my own verification-gated method for building with coding agents.
07
You need the interface designed, not just built.
UX and visual design
Teams without a designer · founders who need the product designed as well as engineered
Design is where this started. Human-computer interaction, interface design and computer graphics were what I took every chance to work on during my studies, and six years at Zeplin then put me inside the handoff itself, the product designers and engineers both opened every day. I work in Figma and Sketch as tools I design in, not just files I read, which means the person drawing the screen and the person building it can be the same person.
What I do
- Design the interface itself: information architecture, screen flows, states and the interaction model.
- Build the visual system of type scale, colour roles, spacing, components and variants, as tokens the codebase can consume directly.
- Draw the pages in Figma from scratch where there is no designer, or work alongside yours where there is.
- Wire Figma into the build through the Figma MCP server, so the design file drives the code instead of being re-typed into it.
- Review an existing interface against interaction fundamentals rather than taste, and say which parts are actually costing you.
You get
- A Figma file that is a source of truth rather than a picture: real components, variants and bound variables.
- Design tokens that arrive in the codebase as tokens, so the built screen and the drawn one cannot drift.
- The reasoning behind each decision, argued from interaction principles rather than preference.
- A design-to-code workflow your engineers can keep running without me.
Engagement
Usually runs alongside a build engagement, since one person drawing and writing the same screen removes the handoff entirely. Available on its own where the engineering is already covered.
Behind it
Six years at Zeplin.io, the design-handoff product designers and engineers shared; the eminakkoc.com 3D portfolio, modelled and drawn as well as coded; this site, designed in Figma and built through a Figma MCP workflow.
How it starts
First engagement.
It begins with me understanding the system well enough to tell you whether I'm the right person for it.
01
You describe it
A message with the system and the symptom. Rough is fine. I would rather read the real problem than a tidy specification.
Same week
02
We talk it through
A call where I ask the awkward questions. You will get my read on the problem whether or not we work together.
45–60 minutes
03
I write a proposal
Scope, sequence, what I am accountable for, what I need from you, and the price. One page, no ambiguity.
Within 3 days
04
We start small
The first increment is deliberately short so we both find out how this works before either of us is committed.
One week
Terms
The practical part.
How I price
Fixed price per increment where scope allows it, day rate where it does not. Rate on request. Tell me the engagement and I will tell you the number.
Where I work
Remote from Türkiye, working with teams across Europe and beyond. Comfortable overlapping with European hours; travel for onsite time when a project warrants it.
Language
Turkish and English, professionally.
Availability
I take a small number of engagements at a time so each gets real attention. Ask and I will tell you honestly when I could start.
Not sure which one
you need? Describe it.
Tell me what the system is and what isn't working. I'll tell you which of the above fits, or that none of them do.