Hiring someone to build systems inside your business is a significant decision. You're giving them access to your tools, your data, your workflows, and your team's time. Getting it wrong is expensive. Not just in dollars — in the months it takes to undo something that was built wrong.
I'm going to tell you how to evaluate this well. That includes some things that might rule us out for your situation. That's fine. A bad fit either direction wastes everyone's time.
Consultant vs Builder — Know What You're Hiring
The first question to ask any automation vendor is simple: do you build, or do you advise?
Some firms will take your money, spend several weeks learning your business, and hand you a strategy document. A roadmap. A recommendation deck. That document might be excellent. But you still have to go find someone to build what's in it, and the person who built the document usually isn't the one who builds the system.
Others build. They come in, understand the problem, and implement the solution. The deliverable is a working system. Not a PDF about a working system.
Neither model is inherently wrong. They're just different things at different price points with different timelines and different outcomes. Know which one you're hiring before you sign anything.
At Onizuka Studio, we build. The intake conversation is how we understand your business. The deliverable is something that runs.
Red Flags Worth Knowing
They can't show you anything they've built.
A contractor you're considering for a home renovation should be able to show you previous work. Same principle applies here. If someone can't point you to live examples, case studies, or specific builds they've completed. That's worth asking about directly.
They recommend a solution before understanding your process.
Good automation work starts with understanding how your business actually operates. If someone leads with "you need Zapier" or "you need a CRM build" before asking how you work, they're selling a product, not solving your problem. The tool should follow the need, not the other way around.
The scope is vague and the timeline is "it depends."
Everything depends on something. But a vendor with real experience should be able to give you a realistic range based on what you've described, explain what variables affect that range, and be honest about what they don't know yet. Indefinite timelines and scope that never gets nailed down are how projects run forever.
They can't explain what they're building in plain English.
If you ask "what exactly will this do when it's done" and the answer is full of jargon with no clear picture of the outcome, that's a problem. You should understand what you're buying. If they can't explain it clearly, either they don't understand it themselves, or they don't think you need to.
The price is suspiciously low.
A cheap automation build usually means one of three things: it's simpler than you think it is, it's being built by someone junior while a senior person takes the meeting, or corners are being cut you won't discover until something breaks. None of those are always deal-breakers. Know which one you're looking at.
Green Flags That Actually Mean Something
They ask more questions than they answer in the first conversation.
A good intake process is mostly listening. The vendor should want to understand your process, your tools, your team, your pain points, and what "done" looks like before they recommend anything. If the first call is mostly them talking, that's a signal.
They tell you what they won't do.
Vendors who are honest about the edges of their expertise are easier to trust than vendors who say yes to everything. If someone tells you "we're not the right fit for that specific thing." That's a green flag, not a problem.
They can point you to something running right now.
Live examples. Real clients. Something you can look at or interact with. The gap between "we've done projects like this" and "here's one" is real.
They talk about maintenance before you ask.
Any build needs ongoing attention. APIs change, platforms update, business processes evolve. A vendor who factors this in from the start (who talks about what happens after launch before you even bring it up) has done this enough times to know it matters.
Questions to Ask Before Hiring Anyone
These work for us. They work for anyone else you're evaluating.
**Who actually does the work?** In some firms, the person you meet is the sales rep. The build goes to a team you've never spoken to. Know who's actually doing the work.
**What does your build process look like, start to finish?** A real answer to this question looks like: here's how we scope, here's how we test, here's how we document, here's how we hand it off, here's what support looks like after. Vague answers are a flag.
**What happens if something breaks after launch?** This is where you find out if there's a support structure or if you're on your own the moment the project closes.
**Can you show me something similar to what I need?** Not a general portfolio. Something close to the specific problem you're trying to solve.
**How do you price your work?** Hourly, project-based, or retainer all have tradeoffs. Hourly is transparent but hard to budget. Project-based is easier to budget but requires a well-defined scope upfront (and scope changes get complicated). Understand what you're agreeing to.
**What would make this project fail?** A good vendor has seen projects fail. They know the warning signs. If the answer is "nothing, we handle everything," that's not real. A real answer sounds like: if the underlying data is inconsistent, if we can't get access to the right systems, if the process changes mid-build. Those are honest answers from someone who's actually been through it.
Questions Specific to Onizuka Studio
Since we're on the topic — here's what we'd tell you if you asked us directly.
**Who builds the work?** Michelle and Michael Onizuka, with Daniel Valadas on back-end DNN development when relevant. You talk to the people building your system, because that's us.
**How do you handle scope changes mid-project?** We document clearly what we're building before we start. If something changes mid-project, we talk about it. We don't surprise you with overages. We also don't let a project die because the path had to change. The deliverable doesn't move even when the route does.
**What does support look like after launch?** We stay. That's one of the things that actually differentiates us. We monitor, adjust, and are reachable. Not a ticket queue.
**What would make a project with you fail?** If a client's data is a mess and they're not ready to address it. If the process we're automating isn't yet defined. If we can't get timely access to the tools we need to build with. We'll tell you this during intake if we see it coming.
The Honest Version
The best automation vendor for your business is the one who understands your operation, builds what you actually need, and is still reachable six months later when something needs adjusting.
Ask the questions. Check the work. Trust the answers that are specific over the ones that sound good.
If we're the right fit, we'll know it after the first conversation. If we're not, we'll tell you that too.
Michelle Onizuka is co-founder and Systems Architect at Onizuka Studio. She has been building automation and AI systems for small and mid-size businesses since 2013.
[Start with an Automation Audit](/automation-audit/) — it's the lowest-pressure way to have the first conversation.