AI engineer · 8 years · TwoWeeks
I build the systems behind the feature: the data, the models, the checks and the product around them. One person takes it from the first call to operations, and every two weeks you get something you can actually use.
You hear a lot about what AI can do, but nobody tells you concretely how it fits your own work.
The chatbot that looked great in the demo gives odd answers to real customer questions and real data.
When the contract ends, the code, the documents and the know-how stay with the agency.
You get a single number, with no way to see why it costs that or what dropping a feature would save.
I build a small version on your real documents, calls and data, and only the features that prove useful go into full development.
You see progress as something you can click through, not as a status report.
You see what each feature costs, so you can drop what you do not need and pay only for what you do.
Eight things, each one shipped before. Click a card for how it works and where it has run.
Your team asks in plain language; the assistant reads your own files, answers with the source shown, and can act on the answer — draft the reply, fill the form, open the ticket. When the source is not there, it says so.
Running live inside the production app of a $500M+ revenue company.
When your knowledge is about how things relate — crops and treatments, parts and failures, rules and cases — a graph answers questions a document search cannot.
Built and shipped for a Fortune 500 subsidiary — the ontology, the extraction, the database and the agent on top.
A team of AI agents does the research, scoring and drafting for one business workflow; a human approves before anything leaves the building.
Export-buyer reports live at FederationLabs; a 20-agent marketing pipeline with two approval gates at STIA.
Turn source material — recordings, PDFs, web data, a curriculum — into real PowerPoint, Word and Excel files that match your templates and open ready to edit.
Classroom decks for paying teachers at MangoFactory; consulting reports from phone calls for an agricultural enterprise.
When an API is too expensive, too slow, too inaccurate or not private enough, I fine-tune a model on your data and deploy it on your hardware — the training and the serving, both, for text and for speech.
In-house models replaced GPT-4 in a 1M-user product; fine-tuned speech recognition at 10.45% error on real farm calls where the commercial API scores 16.39%.
“It doesn’t work well and we can’t tell why.” I turn that into numbers, then into an evaluation-and-optimisation loop that improves them release after release — the same loop that took my own models to state of the art.
A state-of-the-art scoring model built with this loop (arXiv 2309.02740); a $18K, five-star fact-checking engagement; my own unattended agent runner in daily use.
Frontend, backend, database, deployment. No engineering team yet? I build the product around the AI as well, and hand it over in a form a team can take on later.
MangoFactory — a paying SaaS built solo, end to end, in five months; the crop-monitoring dashboard and gateway at an LG subsidiary.
Before anything is built, we find which of your processes gain the most from AI, prove it with a small pilot on your own data, and only then scale.
Every case study on this page started this way. The two-week prototype package is the pilot.
Together we look at the problem and the data you already have. Call recordings, documents, databases: anything works.
Hours and cost per feature, plus milestones, in one document a CEO can read and decide on.
Every two weeks you get something to use, and your feedback goes into the next two weeks. Each milestone has a written test you run yourself; payment follows the test.
I verify performance with measured numbers and hand over all code, documents and runbooks. I stay on after launch.
Every feature is broken into the hours it takes and shown in a table, so you can see what each line costs. Parts I have built before cost their integration hours, and the quote says which rows those are.
Core, then extend, then refine. You choose how far to go.
A smaller budget does not mean lower quality. I cut scope instead, and design it so the rest can be added later. Every scope also lists what is not included.
| Package | Feature | Hours |
|---|---|---|
| 1 · Core | Document collection & cleaning pipeline | 24h |
| 1 · Core | Chatbot that cites its sources | 40h |
| 2 · Extend | Admin console & answer-quality dashboard | 32h |
| 3 · Refine | KakaoTalk & app integration | 24h |
Find out in two weeks, on your own data, whether the idea actually works, before you commit to a big budget.
Agree on the goal and success criteria, and gather the data.
Get one core feature actually working.
Run it on real data, measure, and fix.
Review the results together and settle the scope and quote for full development.
Eight case studies, names used with permission. Click one for the full story, including the technical detail.
TestGlider, an English-test practice service. I built and served the essay and speaking scoring models.
Farmhannong, an LG subsidiary. My crop-consulting AI runs inside its production app and has been rolling out to all farms since May 2026.
For example, on farm phone calls a commercial speech API got 16 of every 100 characters wrong. My model gets 10.
A first version running on your own data, ready for you to try within two weeks.
MangoFactory. A paying SaaS for teachers, built alone from the first line of code to launch.
TestGlider raised this with my scoring model as its core technology. The model was shown to be state of the art in a published paper.
Every sentence the AI writes points to where it came from. If it cannot, the sentence is dropped.
A large agricultural company runs a consulting service for farms. Its best knowledge lived in expert guidelines, years of consulting reports and the consultants’ own phone calls. None of it was reachable at the moment a farmer or a junior consultant needed it. Writing up a consultation took as long as the visit itself.
Three things that share one brain. A knowledge graph of the company’s agronomy know-how, built from their documents with quality control by their own experts. An assistant in the app (web and KakaoTalk) that answers with citations and refuses when the source is not there. And a report copilot that turns a recorded consultation into a per-topic report, then exports it to PDF. Every bullet points to the sentence in the call it came from.
The assistant and the report copilot run inside the production app. The pilot is expanding to all farms from May 2026. The company’s team can extend the graph after handover, because the method, not just the result, was delivered.
Trained on 1% of the client's own calls. The other 99% is the roadmap.
Consultants speak with farmers by phone all day. Those calls hold the facts that should end up in the farm’s diary and the consultation report. But generic speech recognition mangled the crop names, chemicals, brand names and local terms, and users stopped trusting the transcripts. Off-the-shelf engines are trained to score well on news and studio conversation; nobody optimises them for farming calls on a mobile phone.
Four parts. A human-review platform where the team corrects transcripts and builds the training set. A fine-tuned speech model with speaker separation, served on the company’s own GPUs. A 56,000-entry farming vocabulary that feeds recognised terms back to the engine as hints. And a gateway that every other system calls — batch or streaming, with or without speaker labels. Downstream, the transcript feeds the report copilot.
Measured on 2,354 sentences from the client’s real calls, with the same scoring rules for every engine. Our engine: 10.45% character error rate. The leading commercial Korean speech API: 16.39%. The open-source model we started from: 16.18%. On everyday conversation the engine stays level with the commercial API (7.16% vs 7.33%), and on public mobile-phone recordings it is ahead (10.54% vs 11.56%). By the industry’s usual reading, around 20% is “usable but double-check” and around 10% is “trusted”. The client moved from the first band to the second — with only about 1% of their recorded calls labelled.
The in-house model did not just match the API. It replaced it in production.
TOEFL and IELTS learners want to know, right now, what their essay or spoken answer would score. Human graders do not scale, and paying a vendor for every answer does not either. The scores also had to hold up: a junk answer must score zero, and the score the user sees must be the score the model produced.
The company’s own essay-scoring model — the research behind it was state of the art when published — and a speaking-scoring model that listens to the audio and reads the transcript. Later, an in-house correction model that replaced the GPT-4 pipeline, and a self-hosted speech-to-text service that replaced the vendor bill. All four ran as production services on AWS with a test harness that checked the live models on every deploy.
The product scaled to nearly a million users on models the company owned, and the AI was a core part of a $5M+ raise.
Not a slide picture. A real deck a teacher can open and change.
Korean elementary teachers spend their evenings making lesson decks, worksheets and quizzes. The client wanted a product that produces those files — in the school’s own design, editable, aligned to the curriculum — from a short description of the lesson.
The whole product: the teacher-facing app, the admin console, the backend, and the generation agents. The core is a template engine that fills the client’s own PowerPoint in place, so the branding is the template itself and every text box stays editable. A retrieval layer over a 120GB+ corpus grounds the content; images are chosen by meaning, not keyword.
Teachers pay for it and use the output in class. The deck length follows the lesson duration; the template survives untouched.
The report grades each buyer, and the grade has a reason attached.
Finding the right overseas buyer for a product used to take an analyst days per product: classify the goods, search companies, pull trade data, check regulations, rank, write. The client wanted that as a product.
A multi-agent pipeline of eight crews. One extracts the trade classification, one searches companies, one pulls trade records, one researches regulations. One scores buyers, one writes, one checks quality and revises, and one lets the user chat over the finished report. Grades are based on real trade records, and the writer must survive its own critic.
The service went from an idea to a deployed product in four months and is live today.
Five stars, eighteen thousand dollars, and a component you can drop into any pipeline.
Their product answered questions from reference documents, and sometimes the answers contained things the documents never said. They needed to know which sentence was wrong, automatically, and to fix the answer rather than throw it away.
A pipeline that turns an answer into subject–predicate–object claims and checks each claim against the reference. When too many fail, it re-prompts with the exact failure map, so the rewrite fixes what was wrong and keeps what was right. Delivered as an installable SDK with baselines and an evaluation kit so the client can measure it on their own data.
The client left a five-star review. The component is transferable: it plugs into any question-answering system that has reference text.
Two more projects are under NDA.
They are described below without the client, the industry or any figures, so you can judge whether the capability fits your problem.
An AI companion that remembers the user across conversations and stays inside strict behavioural limits, including when parts of the system are unavailable: it degrades gracefully instead of failing.
The AI brain and the client's platform are separated by a written interface contract with a stub mode, so their engineers integrate against a stable surface while the AI evolves behind it.
No split between sales and engineering. The AI engineer with eight years of experience who built the cases above takes the first call, designs the system, builds it and runs it. The person you talk to is the person who writes the code.
Code, trained models, design documents, evaluation sets and runbooks all become your assets. Vendor parts are called "integrate", never hidden as "built".
Instead of "it works well", I report performance as numbers measured on the same data, by the same standard. Features that measure zero gain are switched off and documented.
Monitoring, incident response, retraining and new features: I stay on after launch.
With AI projects, a lot is unknown until you actually use the thing. Seeing something that works every two weeks lets us correct course early, which means less wasted money.
Yes. Source code, trained models, data-processing scripts and design and operations documents are all handed over, and what is handed over is written into the contract.
Fixed price per milestone. Each milestone comes with a written test you run yourself, and payment follows the test, not the calendar. Through Upwork or a direct contract with TwoWeeks.
I check it with numbers measured on real data. For speech recognition, for example, I ran the same 2,354 call sentences through my model and a commercial service and compared the errors side by side.
That's fine. I start by turning scattered documents, recordings and spreadsheets into something usable.
Both. I work through my company, TwoWeeks, and also through Upwork. Either way you work with me directly.
Message me on Upwork with the problem you want solved. You leave the first call with the problem stated in one sentence and a view on whether AI is the right tool for it. And if not, what is.
Working in Korea? The same work is offered through my company, TwoWeeks. twoweeks-acu.pages.dev ↗