.../faq
FAQ
Common questions about who we are, what we do, and how we work.
$ cat ./faq/who-we-are.txt
Who are you?
BrainOps is a small software product studio working at the intersection of AI, automation and internal tools.
We design and build:
>systems that remove manual work,
>tools that help people reason about complex data,
>MVPs and features that can actually be used and sold.
Based in Aotearoa New Zealand. Working with clients globally.
$ cat ./faq/what-you-do.txt
What kind of work do you actually do?
Most of our work falls into a few buckets:
>Automation & internal tools — workflow automation, dashboards, and operations tools that remove manual steps for teams.
>Embedded AI assistants — AI helpers that work with your data and systems, not superficial website widgets.
>MVPs & product features — small, focused products and features that can be shipped and tested with real users.
>Rescue & diagnostics — audits, "what is going on here?" work, and getting half-built products over the line.
If your problem lives somewhere in this space, there is a good chance we can help.
$ cat ./faq/fit.txt
What is a good fit for BrainOps?
Good fit looks like this:
>You have a concrete problem — missed revenue, manual work, slow operations, scattered data, or a product that is stuck in "almost ready".
>You want a real outcome — less manual time, fewer errors, faster throughput, clearer decisions, a shippable MVP.
>You can decide — one or two people who can say "yes", "no" and "done", with a budget and a rough timeline.
>You are open to short, honest cycles — fixed-scope sprints, with a real deliverable every 1–2 weeks.
$ cat ./faq/not-fit.txt
What is NOT a good fit?
We are probably not the right studio if you need:
>"Just a website" with no real logic or product behind it.
>A large RFP-driven programme with many layers of approvals.
>An open-ended maintenance contract with no clear end.
>Crypto, NFT or gambling projects.
>"We'll pay you in equity later" arrangements.
It is not about judgement. We are optimised for sharp, high-leverage work with a clear finish line.
$ cat ./faq/geo.txt
Do you only work with New Zealand clients?
No. We work globally.
Most of our projects are remote, with clients in New Zealand, Australia, and other regions (Europe, North America, Asia-Pacific).
If you are in Aotearoa New Zealand and your project clearly helps the local community — education, public understanding, research, or tools for small businesses and professionals — tell us.
For qualifying NZ projects we try to work closer to the lower end of our price ranges or structure a smaller, focused engagement first.
$ cat ./faq/nz-software.txt
Do you offer custom software development in New Zealand?
Yes. BrainOps is based in Aotearoa New Zealand and builds custom software, internal tools, and AI-driven systems for local and international clients.
We work remotely with businesses across New Zealand — including Auckland, Wellington, Christchurch and regional centres — as well as clients in Australia, Europe, North America and Asia-Pacific.
$ cat ./faq/nz-smb.txt
Can you help New Zealand small businesses with automation and AI?
Yes.
We work with New Zealand small and medium businesses that want to:
>remove manual work from their operations,
>connect scattered systems and data,
>use AI to summarise, triage and explain what is happening.
If you are a NZ business owner and have a specific process or workflow that feels slow or fragile, we can usually turn that into a focused automation or internal tool sprint.
$ cat ./faq/pricing-link.txt
How does your pricing work?
We work in fixed-scope sprints.
>Discovery & diagnostics to map the problem and risks.
>Automation & internal tools to remove manual work.
>Embedded AI assistants to make systems easier to understand and operate.
>MVP & feature sprints to ship usable product slices.
>Rescue sprints for stuck or half-built systems.
Each sprint has a clear scope, a fixed price, and a tangible deliverable.
For detailed ranges, see:
>_pricing# rates & packages$ cat ./faq/process.txt
What does working together look like?
Roughly:
>You send us a short description of who you are, what you are trying to do, and why now.
>We reply with first thoughts and a few sharp questions. If it looks like a fit, we schedule a call.
>We start with a small, fixed-scope diagnostic or discovery sprint.
>Based on that, we propose one or more build sprints with clear outcomes, timelines and prices.
>After each sprint we stop, review what we shipped, and decide together: stop, extend, or park.
No endless roadmaps, no "billing just in case".
$ cat ./faq/method.txt
How do you ensure quality?
A few principles:
>Builder ≠ verifier — someone else reviews before merge.
>Tests before merge — no "we'll add tests later".
>Docs before done — if it's not documented, it's not finished.
>Clean handoff — code, tests, docs, ownership transfer.
$ cat ./faq/intake-assistant.txt
What is the intake assistant?
The intake assistant is a conversational AI that helps you describe your project before we talk.
It asks about your role, what you are trying to build, current state, budget range, and timing.
At the end it generates a brief — a structured summary we can use to prepare for a call.
>No forms to fill. Just a short conversation.
>Voice input supported if you prefer talking.
>Your session is saved — you can come back and continue.
It is not a sales bot. It just helps us understand your situation faster.
Try it:
>_assist# intake assistant$ cat ./faq/ai.txt
Do you build AI assistants?
Yes, but not generic chatbots bolted onto a website.
We build embedded AI assistants that:
>work with your own data, logs, metrics and docs,
>can run health checks and surface anomalies,
>explain what is happening in plain language,
>help new people onboard without reading a hundred pages of documentation.
If you want "yet another marketing chatbot", we are not the right studio. If you want an assistant that understands how your system behaves, we might be.
Ready to talk?