# Amit Kuzi — Process engineering for software, AI and 3D printing > Independent consulting: software architecture and modernisation, applied AI, and 3D printing materials and process. --- # Software > Architecture, .NET modernisation, data migrations and engineering management — for systems that are already carrying load. Source: https://amitkuzi.com/services/software/ Most of this work starts the same way: a system that shipped years ago is still shipping, and the cost of changing it has quietly overtaken the cost of running it. Framework versions that no longer get patches, a database that was the right shape for the first product and the wrong shape for this one, a team that spends more of the week on incidents than on the roadmap. The method is the same in all six services below. Measure the process before arguing about it, name the failure modes in order of what they cost, and move in steps that can each be released on their own. ## What you get - An assessment that ranks failure modes by cost, not by how loud they are - A migration plan in releasable steps, not a rewrite - The work done alongside production traffic, not instead of it --- # .NET 10 development & modernization > New services on .NET 10, and existing ones brought up to it without a rewrite. Source: https://amitkuzi.com/services/dotnet-10-modernization/ Modernisation is usually sold as a rewrite and delivered as a two-year outage of feature work. It does not have to be. Most .NET codebases can move version by version, project by project, with each step released on its own and each step reversible. Where the code is new, .NET 10 is simply the target: minimal APIs, the current hosting model, and containers from the first commit rather than bolted on later. ## What you get - A dependency and blocker map before anything is touched - An upgrade path in releasable steps, ordered so the risky parts land early - The obsolete APIs replaced, not wrapped - A build that produces a container image, and a test suite that runs in CI --- # .NET Framework → .NET 10 migration & Docker/Linux hosting > Off Framework, off Windows Server, onto Linux containers — while the system keeps serving traffic. Source: https://amitkuzi.com/services/framework-to-net10-migration/ The parts that hurt are rarely the language. They are the Windows-only dependencies, the WCF endpoints, the registry and file-system assumptions, the COM interop somebody added in 2011, and the deployment that lives in a person's head. Those get found first, priced, and dealt with one at a time. I have run this migration on production systems, including converting legacy CoreWCF services to REST APIs with an AI-assisted conversion rig where the volume justified building one. ## What you get - An inventory of every Windows-only dependency, with a decision per item - WCF and legacy endpoints mapped to their replacements - A Dockerfile and a Linux hosting setup that your team can operate - Cutover done in stages, with a way back at every stage --- # Relational → NoSQL migration > Moving to a document store when the access pattern justifies it — and saying so when it does not. Source: https://amitkuzi.com/services/nosql-migration/ A document database is not a faster relational database. It is a different set of trade-offs, and it pays off when the access pattern is known, the read shape is stable, and the joins you are doing today are the ones the model should have avoided. When that is not the case, the honest answer is an index and a schema change, and I will give you that answer. When the move is right, the work is mostly modelling and migration mechanics: designing documents around how they are read, then getting the data across without a maintenance window. ## What you get - A read/write access pattern analysis before any schema is drawn - A document model designed around queries, not around the old tables - A dual-write or backfill migration path with verification at each stage - The consistency and transaction assumptions written down, not discovered later --- # ETL & data migration > Pipelines that finish, restart cleanly, and tell you when they lied. Source: https://amitkuzi.com/services/etl-data-migration/ A data pipeline is a chemical process with different units: something enters at a rate, something leaves at a rate, and there is a bottleneck. The failures are the same too — the run that half-completed, the source that changed shape without telling anyone, and the reconciliation nobody does because it was never built. This covers both the recurring pipeline and the one-off migration of a system from A to B, including the boring part that decides whether it worked: proving the two sides match. ## What you get - Throughput and bottleneck measured before the pipeline is redesigned - Idempotent, restartable jobs — a failed run costs one rerun, not a weekend - Reconciliation between source and target, as a check that runs on its own - Alerting on the failure that matters: silently wrong data, not just a crash --- # Microservices, high availability & architecture review > A review that ends in a ranked list of what will break first, and what it costs to fix each one. Source: https://amitkuzi.com/services/architecture-ha/ Most architecture reviews produce a diagram. This one produces an order: the failure modes that are actually reachable, ranked by what they cost when they happen, with the cheap mitigations separated from the expensive ones. The high-availability side comes from years on services where redundancy and concurrency were the product, including Power Query Dataflow at Microsoft and a collision detection engine that ran without a crash in production. ## What you get - Failure modes ranked by cost and reachability, not by severity labels - Service boundaries assessed against the actual coupling, including the database - Concurrency, retry and idempotency assumptions checked where they matter - A document another engineer can execute without me in the room --- # Engineering management consulting > For a team that is busy every week and shipping less than it used to. Source: https://amitkuzi.com/services/engineering-management/ The delivery process is a process like any other, and the same four questions apply: what goes in, what comes out, where the queue builds up, and what breaks when you push more work through than the design assumed. Usually the bottleneck is not the number of developers — it is review latency, an environment nobody trusts, or an on-call load that eats the same two people every sprint. I have run R&D at VP level with a 25-person team split across two countries, and led hands-on as a team leader through a full platform migration. The advice is from having had the problem, not from a framework. ## What you get - Where delivery time actually goes, measured rather than estimated - The bottleneck named, with the two or three changes that move it - Hiring, structure and on-call load reviewed against what you ship - Coaching for team leads, if that is the constraint --- # AI > LLMs and agents placed inside a stack that already exists, as a step in a process that runs without anyone watching it. Source: https://amitkuzi.com/services/ai/ A demo proves a model can do something once. A process proves it does the same thing on Monday morning, on the messy input, with nobody in the room. The gap between those two is where almost all AI projects stall, and it is engineering work rather than model work: where the data comes from, what happens when the answer is wrong, and who finds out. Two services here, one for teams building software and one for a business that wants specific hours of routine work to stop existing. ## What you get - A shortlist of the tasks in your business that are actually worth automating - Model choice, cost per run and failure behaviour decided before anything is built - An integration into the stack you already run, with a way to measure whether it holds --- # AI/LLM-driven development > Using models inside your engineering process — migration rigs, code conversion, review — with the output verified rather than trusted. Source: https://amitkuzi.com/services/ai-driven-development/ The productive use of an LLM in engineering is rarely "write this feature". It is the repetitive, mechanical, high-volume work: converting a few hundred service endpoints, translating a legacy pattern into the current one, drafting the tests for code that never had any. The value comes from the verification step around the model, not from the model. I built exactly this at GreenRoad — an AI-assisted rig that converted legacy CoreWCF services to REST APIs — and the lesson was that the harness matters more than the prompt. ## What you get - The tasks in your pipeline where a model beats a person, and the ones where it does not - A conversion or generation harness with verification built into it - Cost per run and failure behaviour measured before it goes wide - Your team able to run it after I leave --- # AI for SMB: cost saving, routine work automation, customer & sales management > Specific hours of routine work every week, identified and then automated — starting with the ones that pay back fastest. Source: https://amitkuzi.com/services/ai-for-smb/ For a small business the question is never "what can AI do". It is which two or three hours a week are being spent on something a machine does adequately: quotes, order intake, answering the same customer question, chasing a supplier, moving data between two systems that do not talk. We start by counting those hours. Then we automate the ones with the shortest payback, using the tools you already pay for wherever possible. ## What you get - A list of your routine tasks with hours and cost attached to each - Two or three automations built, in order of payback - Integration with the systems you already use, rather than a new one to learn - Running costs stated up front, and what happens when the model gets it wrong --- # 3D printing > FDM as a production process — part design, material selection and tuning, up to a print that repeats. Source: https://amitkuzi.com/services/3d-printing/ An FDM machine will make one good part for almost anyone. Making the tenth part match the first is a process problem: material behaviour, geometry that fights the process, and settings nobody wrote down. That is chemical engineering with a nozzle instead of a column. Three services, from a workshop buying its first machine to one with printers running and a scrap rate it cannot explain. ## What you get - A machine, material and process choice justified against the parts you actually make - Design rules for your parts, so the geometry stops causing the failures - Documented settings a second person can run without you standing there --- # Getting started with FDM > For a workshop deciding whether to buy a printer, and what to buy — before it becomes a shelf ornament. Source: https://amitkuzi.com/services/fdm-getting-started/ The machine is the cheapest part of the decision. What decides whether it earns its place is the parts you intend to make, the material they have to survive, and who in the shop is going to run it on a Tuesday when it fails mid-job. We work backwards from your parts to the machine, not the other way around. If the honest answer is that outsourcing is cheaper for your volume, that is the answer you get. ## What you get - Machine and enclosure choice matched to your parts and your space - The real running costs: material, failed prints, maintenance, operator time - A first set of working profiles, not factory defaults - One person in the shop trained to run and unblock it --- # CAD & design for FDM > Parts designed for the process that makes them — so they print without a fight and hold up in use. Source: https://amitkuzi.com/services/cad-for-fdm/ A model that is correct in CAD can still be a bad part: layer lines across the load path, an overhang that needs support inside a bore, a tolerance that ignores how the material shrinks. Most print failures in a working shop are design decisions showing up later, not machine problems. This is CAD work — in FreeCAD or your existing toolchain — plus the design rules that keep the next part from having the same problem. ## What you get - Parts modelled or reworked for the direction they will actually be printed in - Load paths oriented against the layer lines, not along them - Tolerances and fits that account for the material and the machine - Design rules written down for whoever draws the next part --- # Material selection & process tuning > Choosing the filament for the job and tuning the process around it, until the tenth part matches the first. Source: https://amitkuzi.com/services/materials-and-process/ Filament is a polymer with a processing window, not a colour choice. PLA, PETG, ABS, ASA, nylon and the filled variants each have a temperature range, a moisture problem, a shrinkage figure and a failure mode, and picking the wrong one is the most expensive mistake a workshop makes because the parts look fine until they are in service. Tuning is the measurable half: flow, temperature, cooling and speed, changed one at a time against a printed test rather than against an opinion on a forum. ## What you get - Material chosen against the part's real service conditions — heat, load, UV, chemicals - Drying and storage handled, because most "bad filament" is wet filament - Flow, temperature, cooling and speed tuned one variable at a time, on test prints - A documented profile per material, so a second operator gets the same result