Nadia Mohamed
Discovery
The problem in your words, the current workflow, the success criteria, the constraints. A short written brief comes back from this — what we're building and what we're not.
Service · AI tooling & automation
AI-Powered Tools & Software — custom applications and automation that ship
Custom AI applications, n8n automation pipelines and internal tooling — built to solve a real workflow problem, not to demo what AI can do. Engineering-grade implementations, not slide-deck prototypes. The free AI tools at nadiamohamed.me/ai-tools are examples of the shape.
When this is the right call
Most AI tooling work falls into a few recurring shapes. The pattern that signals this is the right engagement:
- A workflow eats hours every weekManual content tagging, lead enrichment, SEO ops, brief generation — something that's repetitive enough to automate and important enough to do well.
- You prototyped in ChatGPT and need to ship itThe hand-driven prompt chain works in conversation, but turning it into a tool the team can use reliably is the unsolved part.
- Off-the-shelf tools nearly fit, but don'tThe SaaS option is 70% there, the gap is the part that matters most, and the custom build pays back inside a year.
- You need an internal interface, not an exportThe team is currently pulling data into spreadsheets to do the work — a small internal tool replaces the spreadsheet round-trip with something maintainable.
- n8n automations that need to be designed, not just draggedThe workflow needs error handling, idempotency, retry logic — engineering thinking on top of the visual builder.
- An AI feature for your own productYou're shipping AI inside your product and want it built right the first time — model choice, prompt design, eval harness, cost control.
What you get
Project-scoped, but every engagement produces the same five artefacts so you inherit a maintainable system, not a one-off demo.
-
Design document
The problem framed, the chosen approach, the trade-offs taken, the model and stack decisions explained. The artefact whoever inherits the tool starts with.
-
Working application
Shipped, running, with the interface your team actually uses — web app, CLI, n8n workflow, internal dashboard, depending on the shape of the problem.
-
Source code & infrastructure
In your repo, deployable from your CI, hosted where you host things. No vendor lock-in to my accounts or my tooling.
-
Evaluation harness
Where AI quality matters — citation accuracy, classification correctness, retrieval relevance — a test suite that lets you tell when quality degrades and re-tune the prompts without guessing.
-
Documentation + working session
How it works, how to extend it, how to debug it, what the recurring costs look like — plus a session with the team that will own it.
How it works
Four phases. Total elapsed time depends entirely on scope — small tools land in two to three weeks, larger applications take longer.
Prototype
Smallest thing that proves the core mechanic — usually a notebook or quick script. You poke at it; we confirm the approach holds before committing to the build.
Build
Production-shaped implementation — error handling, retries, observability, cost controls, the interface. Code lands in your repo as it goes; no surprise reveal at the end.
Handover
Documentation, walkthrough, training session, the eval harness. You can extend it from here without me; I'm available for the first month if something breaks.
How this works alongside your team
AI tooling touches engineering, product and the team that will use the thing. The engagement is shaped to be additive to all three.
If you have an engineering team
The code lands in your repo, follows your conventions, integrates with your CI. I'll match the patterns your team already uses rather than imposing mine. You inherit a project, not a black box.
If you don't (yet)
Smaller tools and n8n workflows can run on managed infrastructure your team can operate without a developer. I'll choose the deployment shape so a non-engineer can keep the lights on.
Cost & model choices are surfaced
LLM API costs compound — choices about model, batching, caching, retrieval and fallback matter materially. You'll see the cost model before the build commits, not after.
The user comes to the prototype
The team that will use the tool gets hands on the Phase 2 prototype. If the interaction is wrong, we find out before the build, not after handover.
What this actually moves
The honest version
AI tooling done well moves capacity — what a small team can do without growing, what a senior person spends their time on, what becomes possible because something previously expensive is now cheap.
What it doesn't move on its own is strategy. A great tool sitting on top of an unclear workflow accelerates the unclear workflow. The discovery phase is shaped to push back on that — sometimes the right output isn't the tool that was scoped originally; sometimes it's a simpler tool that does less and does it better.
Common questions
If yours isn't here, drop a line — I'll answer directly and add it.
Which models / providers do you work with?
Whatever fits the job. OpenAI, Anthropic, Google, Mistral, open-source models via local or hosted inference — each has shape-of-task tradeoffs (cost, latency, reasoning, context window, structured output reliability). The model choice is part of the design phase, not a default.
Do you build with LangChain / LlamaIndex / similar frameworks?
Selectively. The frameworks add real value for retrieval-augmented use cases; they add overhead and indirection for straightforward prompt chains. Default is to keep dependencies light and reach for a framework when it earns its place.
How do you handle prompt regression / quality drift?
The eval harness is the answer. For any project where output quality is measurable (correctness, format adherence, citation accuracy, classification), an evaluation set ships alongside the application. When you upgrade a model, change a prompt, or swap a provider, you can tell in minutes whether quality moved — without guessing.
n8n vs custom code — how do you decide?
n8n is the right tool when the workflow is genuinely visual, the team that owns it will edit it, and the failure modes are easily recoverable. Custom code wins when the workflow has complex state, needs serious error handling, or runs at volume. Most engagements end up with a mix: n8n for the visible workflow operators touch, custom code for the engine underneath.
Will the tool keep working when models change?
Yes — that’s the point of the eval harness and the abstraction layer between the application and the model. Provider swaps and version upgrades become testable, not terrifying. You’ll be able to move to GPT-7 or Claude 5 with confidence that nothing silently regressed.
What about ongoing costs?
Two layers: LLM API costs (variable, depends on volume and model choice — surfaced in the design phase with realistic projections) and infrastructure costs (usually small — a few euros to tens of euros per month for most tools). No ongoing license fees to me.
Do you sign NDAs / handle proprietary data?
Yes to NDAs as standard. For proprietary data: the design phase includes the data-handling decisions (which provider, which retention policy, on-prem inference if needed) before any sensitive content touches an LLM.
Got a workflow that should be a tool?
Get in touch with a short description of the problem — what people are doing manually now, how often, what success would look like. I'll come back within 24 hours with whether this is the right engagement and what the next step is.