Loading
AI developer, Canberra ACT
Custom AI products, automation and integrations for Canberra small and medium businesses. I turn a practical business problem into working software: an internal assistant, an automated workflow, AI inside the system you already use, or a complete AI product.
Most businesses have tried ChatGPT by now. The harder question is how that turns into something the business can rely on every day.
Pasting an email into a chat window and getting a decent reply is useful, but it lives in one person's browser, depends on how well they wrote the prompt, and never touches your systems. Each step below is a different kind of project, with its own cost, risk and payoff.
Someone copies information in and copies the answer out. Quick to start, but nothing is repeatable, auditable or connected to your data.
AI does one step inside a process that already runs: reading an incoming email, pulling fields from an invoice, drafting a reply for someone to approve.
The AI feature lives inside the CRM, website, SharePoint site or app your staff already use, working with the data already there.
An assistant or application of your own, behind your sign-in, answering from your documents and respecting who is allowed to see what.
Software you offer to customers where AI is part of what it does. That is a full software product with AI inside it, and it needs to be built like one.
Not every problem belongs at the far end of that list, and some do not need AI at all. Part of the job is working out where yours actually sits.
Six kinds of AI work, described by what they do for the business. Most real projects combine two or three.
Assistants that answer from your own procedures, policies and documents instead of whatever a general model happens to know. Answers point back to their source so staff can check them.
AI handles the reading, sorting and drafting inside a process; rules and people handle the decisions. Often combined with Power Automate, n8n or custom code.
An agent is a model that can use tools: search, look something up in a system, call an API, then decide its next step. I build agents with a defined set of actions, limits on what they can change, and a person approving anything that matters. They are useful for bounded multi-step tasks. They are not autonomous employees.
Web and mobile applications where AI is part of what the product does, for customers or for staff.
Adding AI to software you already have: a website, a web app, a Microsoft 365 environment or a business system with an API. Often the fastest route to value, because the users and the data are already there.
Taking an AI product idea from a conversation to something customers use. The early stages exist to find out cheaply whether the idea works before the expensive stages begin.
AI development for a small business does not mean an enterprise platform. The projects that pay off are usually small, specific and aimed at work someone does by hand every week.
The test is the same for each: what does it save or earn, and what does it cost to build and run at your volume? If a form, a rule or an off-the-shelf tool does the job, that is the recommendation, and it is usually cheaper.
Established organisations have more to connect and more to protect. The AI is often the smaller part of the work; the integration, permissions and governance around it are what make it usable.
I have led development inside Australian federal government departments, so change control, accessibility and security review are familiar ground rather than obstacles.
Eight stages. On a small automation some take an afternoon; on a product each is a phase of its own.
What happens today, who does it, how often, and what a good outcome looks like in hours, errors or revenue. The problem is written down before any technology is named.
Some problems need AI, some need automation or conventional software, and many need a mix. Anything that must be exactly right every time is a poor fit for a model on its own. You get a straight recommendation, including when the answer is not AI.
Where there is real uncertainty, a small proof of concept runs on your actual documents or data. It shows whether the model is accurate enough before the full build is paid for.
The application, integration or automation, built as production software: typed, version controlled and structured so another developer could maintain it.
Connected to the systems, documents and people it needs, with the permissions it should have and no more.
Accuracy on real examples, edge cases, unexpected input, attempts to make it misbehave, security and cost. A model that is right most of the time needs a plan for the rest.
Into production with monitoring, logging and usage limits, and a way to switch the AI step off without taking the whole system down.
Real usage shows where it falls short. Prompts, retrieval, workflows and model choice are adjusted against evidence, and re-evaluated as providers release new models.
An AI consultant identifies where AI could help, recommends tools and writes a plan. That has value, and plenty of Canberra businesses start there. The gap appears afterwards, when the plan needs a developer to turn it into software and the person who wrote it is no longer involved.
As an AI developer I cover both halves. The person who assesses the opportunity also designs the solution, builds it, connects it to your systems and supports it once it is live. The recommendations stay realistic because I am the one who has to build them.
Only want advice for now? That is available too, through IT strategy and advisory.
Discuss your AI ideaIt is the first question most businesses ask, and it deserves a better answer than “it's fine”. Production AI involves far more decisions than pasting company information into ChatGPT.
Most AI features call a model provider's API. You are told which provider, what is sent, and what their terms say about retention and training. The business API tiers I build on do not train on submitted data under their current terms, and I check those terms for each project rather than assuming.
The model receives the passages it needs to answer, not your whole document store. Personal or sensitive fields can be removed or masked before anything leaves your system.
Users sign in, and an assistant only retrieves documents that person is already allowed to see. AI should never become a way around your existing permissions.
Explicit rules about what the AI can read, what it can change and what it can never touch. Agents get narrow, specific tools rather than broad access.
API keys stay on the server, connections use the least privilege that works, and actions are logged so you can see what happened and why.
Provider, model and hosting region are chosen per project. If your data has residency or sector obligations, they shape the architecture from the start, and you are told plainly what a given design can and cannot guarantee.
No system is free of risk. The aim is a design whose risks are understood, written down and proportionate to the data involved.
Chosen per project. None of this needs to mean anything to you before we talk.
OpenAI's GPT models most often, with Anthropic's Claude or Google's Gemini where they suit the task better. The model is chosen on accuracy, cost and data terms for the job, and the system is built so it can be swapped later.
Retrieval-augmented generation (RAG): documents are split, converted to embeddings and indexed for vector search, so the model is handed the relevant passages at the moment it answers and told to say when it does not know.
Function and tool calling for agents that look things up or act through APIs, and structured output validated against a schema, so AI results arrive as data your system can trust rather than loose text.
TypeScript, React, Next.js and Node.js, Supabase for Postgres, auth and storage, and Expo for mobile. Deployed on Netlify or Azure.
SharePoint, Microsoft Graph, Power Automate and Azure, plus REST APIs and webhooks into the business systems you already run.
Projects from the portfolio with AI inside them, from customer-facing apps to internal staff tools.
Project pages carry what each client permits me to publish. No outcome is claimed here that the portfolio does not record.
The AI tools on this site are built the same way as client work. Some sit behind an access code, because every use costs money to run.
MDT Software Development is based in Canberra, ACT. On an AI project you work directly with me, Jayden Marquardt, not an account manager fronting an offshore team. We can meet in person in Canberra when it helps and work over Teams or Meet when it does not.
That matters more for AI than for most software. The early conversations about your process, your data and what the business can tolerate getting wrong decide whether the project works, and they go better with the person who will write the code.
I work with Canberra and ACT businesses, and with organisations elsewhere in Australia.
I'm a senior full-stack software developer, building since 2017. I have led development teams inside Australian federal government departments, including as Software Development Lead at DFAT, and I have built AI features into customer-facing apps, internal staff tools and the tools on this site.
Most of my enterprise work has been in Microsoft 365 and SharePoint, which is where many Canberra organisations keep the documents an AI assistant would need.
The questions Canberra businesses ask before starting an AI project.
It depends mostly on the kind of project. A prototype that tests one idea on your real data is a small, contained piece of work. A single AI step added to an existing workflow is usually modest. An integration depends on how accessible your existing systems are. An internal application or a complete AI product is a proper software project and is priced like one. There is also a running cost: most AI features are charged per use by the model provider, so I estimate that at your expected volume before anything is built. Each project is quoted on its scope with the assumptions written down, rather than from a rate card.
Usually, yes. If a system has an API, AI can read from it and, where appropriate, write back to it. Websites, web applications, CRMs, Microsoft 365, SharePoint and most modern cloud software can be connected. Older systems without an API can often be reached through exports, email or an automation platform, and I will be clear about how robust each route is before recommending one.
Yes. The difference between a useful business chatbot and a frustrating one is almost always grounding: it answers from your own content, says when it does not know, and hands over to a person for anything it should not handle. I build chat assistants for customers on a website or for staff behind a sign-in, connected to the documents and systems they need and limited to the job they are for.
Yes, through retrieval rather than training. Your documents are indexed so the relevant passages can be found and given to the model at the moment it answers. That keeps answers tied to your actual content, lets them cite their source, and means updating a document updates the answers. Access can follow your existing permissions, so people only get answers from documents they are allowed to see.
It can be handled safely, but that comes from design decisions rather than a promise. You are told which provider a feature uses, what data is sent, what the provider's terms say about retention and training, and where the data is processed. The system is then built to send only what is necessary, keep keys on the server, respect user permissions and log what happens. If your data has residency or regulatory requirements, those shape the choice of provider and architecture from the start.
ChatGPT is a general assistant a person uses by hand. A custom AI application is software built around one business job: it connects to your systems and documents, runs the same way every time, controls who can use it and what it can see, validates what the model returns, and fits into a workflow instead of sitting in a separate browser tab. Many custom applications use the same underlying models, accessed through the provider's API.
Yes, where the process involves reading, sorting, extracting or drafting. I map the process first, then decide which steps suit AI, which suit ordinary automation rules and which should stay with a person. A typical result is AI reading incoming emails or documents and preparing the work, with a person approving anything that matters.
Often not, at least not straight away. Off-the-shelf tools with AI built in cover a lot of small business needs, and I will say so if one fits. Custom work makes sense when a repetitive task costs real hours every week, when information is spread across systems a generic tool cannot reach, or when the AI capability is part of what you sell. A small build aimed at one job is usually a better start than a large project.
A focused prototype or a single AI step in an existing workflow can take days to a few weeks. An integration or an internal tool typically takes several weeks. A complete AI product takes months and is best delivered in stages, starting with a version real users can test. Most of the variation comes from integration and testing rather than the AI itself. The quote comes with an estimated timeline.
Yes. We start by pinning down who the product is for and the one thing it must do well, then build a prototype to test whether the AI part performs well enough on realistic input. If it does, the product is built in stages: a first version for real users, then the features, integrations and scale it needs. If the prototype shows the idea does not work yet, you find out early and cheaply.
Both. Many projects begin with advice: where AI would help, what it would cost to run and whether it is worth doing. The difference is that the advice comes from the developer who can build it, so the recommendations stay practical. If you only need an assessment, or a second opinion on someone else's proposal, that is available as a separate piece of work.
You do not need to know which AI model, framework or technology you need. Start with the problem, and I will help work out whether AI makes sense and what it would take to build.
