Questions people ask before getting in touch

It is software that does a repetitive job your team currently does by hand, where part of that job involves reading or judging something. Ordinary automation moves data between systems on fixed rules. AI automation handles the steps where the rule is hard to write down: sorting a message by what it is about, pulling figures out of a document that has no consistent layout, or answering a question from a body of knowledge. The two are usually combined in one system.

Mostly it picks up where rule-based automation stops. If your current tooling breaks whenever a document arrives in an unexpected format, or needs a person to read something before the next step can run, that is the boundary. The work is usually less about replacing what you have than about removing the manual step in the middle of it.

Often just better automation, and that is a normal finding. A language model is expensive and non-deterministic, so it is the wrong tool for a step that a rule handles reliably. The useful question is which steps in your process genuinely need judgment, and those are usually a minority of the steps.

Three things: it repeats on a schedule, it consumes hours somebody could count, and an error in it costs something. A process that runs twice a year is a poor candidate no matter how tedious it is. If you want a number before talking to anyone, the ROI calculator on this site estimates the annual cost of a repetitive task from four inputs.

Then that is usually the first project, and it is better to find out at the assessment than halfway through building on top of it. A retrieval system built on data that contradicts itself produces confident, wrong answers, and the failure looks like an AI problem when it is not one.

I do. Datasmarts is one person, Jesus Martinez, and the person you talk to on the first call is the person who writes the code. There is no account manager layer and no handoff to a delivery team you have not met. The trade-off is capacity: I take on a small number of engagements at a time, so timelines are real rather than optimistic.

With a conversation about your processes, not a specification. We walk through what runs manually today, how often, and roughly what it consumes, and that produces a ranked shortlist with a cost against each candidate. The build, if there is one, is quoted from that shortlist rather than from a wishlist.

Access to the people who run the process, more than access to documentation. The manual corrections nobody wrote down are usually the real requirements, and the only way to find them is to watch the work happen. Beyond that, read access to the systems involved and one person who can make decisions.

It depends on the process, and the assessment is what makes that answer honest rather than a guess. What I can commit to is the shape: the automated version runs alongside the manual one until the outputs agree, so the switch happens when the evidence is in rather than when the build is finished.

It runs on your infrastructure and your accounts, and you can maintain it. Workflows a non-engineer should be able to read stay readable, the parts that are really software are documented and tested, and I hand over what I built. Bringing maintenance in house is a normal outcome rather than a problem.

In two stages. The assessment is priced on its own and produces a ranked shortlist with a cost against each candidate process. If a build follows, it is quoted as fixed scope from that shortlist, so you are approving a specific piece of work at a known price rather than opening an hourly meter. Get in touch with the process you have in mind and you get a number for the assessment.

Because it is the deliverable, not a sales call. It involves walking your processes with the people who run them, putting hours and money against each one, and writing up what to do first and what to leave alone. A free version of that is a pitch with a predetermined conclusion, which is the thing this is meant to be an alternative to.

Then it says so, and you have still got the thing you paid for. Some processes run too rarely to justify the work, some are about to change and would be automated twice, and some are cheaper to fix by removing a step than by automating it. Knowing which of those you have is worth more than a build nobody uses.

Sometimes, if you already know which process and can show what it costs today. What cannot be skipped is the baseline: without a recorded starting number there is no way to say afterwards whether the thing worked, and measuring the result is half of what you are paying for.

No. What gets built runs on your infrastructure and your accounts, and the handover includes documentation of what it does and how to change it. There is no hosting arrangement, no per-seat licence, and no component that stops working if you stop talking to me.

Onto infrastructure you control, by default. Pipelines read from the systems your data already lives in and write results back to a store in your accounts. Where a language model is involved, the relevant text is sent to that model provider for the duration of the call, and which provider that is becomes an explicit decision rather than an assumption.

Often yes, and it is worth asking early because it shapes the design. Self-hosted open-weight models are a real option for classification and extraction, and the trade-off is usually cost and accuracy rather than feasibility. Where the sensitive step can be separated from the rest, a common pattern is to keep that step local and route only the non-sensitive work outward.

Python for the parts that are really software, self-hosted n8n for the orchestration a non-engineer should be able to read, and whichever language model fits each step. Model choice is a design decision that gets revisited, not a vendor commitment, and systems are built so a model can be swapped without a rewrite.

You do. The code, the workflows and the documentation are yours at handover, running in your accounts. Nothing is licensed back to you and nothing depends on a Datasmarts account continuing to exist.

Partly, and the split is deliberate. Workflows that a non-engineer should be able to read and adjust are built to stay that way in the orchestration layer. Anything doing multi-stage language processing, API normalization or state management is written as tested Python instead, because a non-engineer maintaining that is not a kindness to anyone.