Questions, answered properly

Email us or fill in the form at /start/. We’ll reply within one working day and set up a 20-minute call. If it looks like a fit, the next step is usually a Blueprint or an Efficiency Audit — a small, fixed-price piece of work that produces a real scope and a real quote. Nothing is committed until you’ve seen both in writing.

No. Most people don’t, and the ones who do often have a spec that turns out to describe something different from what they actually need. The Blueprint exists precisely to produce that document. Come with the problem, not the solution.

Genuinely small. If a two-day automation fixes your problem, we’ll build that and charge for two days. We’d rather build the small right thing now and the bigger thing in two years than talk you into a system you don’t need. The only projects we turn down for being small are ones where the answer is “buy an off-the-shelf tool” — and we’ll tell you which one.

Multi-user, multi-site systems with role-based permissions and integrations into what you already run. The practical ceiling isn’t complexity, it’s calendar time — Neevo is small, so a project needing twenty people working in parallel isn’t a fit. If that’s you, a larger agency is the right call and we’ll say so.

Usually two to four weeks, sometimes sooner. We run a limited number of projects at once deliberately, so if we’re full we’ll tell you when we’re not rather than starting yours and slowing down.

More than most people expect, and it’s the single biggest predictor of whether a project goes well. Budget two working sessions during the Blueprint, then roughly an hour a fortnight during the build to review each phase. Projects that drift almost always drift because the client went quiet, not because the developer did.

Yes. Twenty minutes, free, no obligation, and no presentation. Book at /start/?path=call.

Yes, though it’s not our focus. Two things to know: we invoice in Rand, and we work South African hours. If you’re in Europe there’s meaningful overlap; if you’re on the US west coast, expect a one-day lag on most exchanges. For a client whose data must stay in a specific jurisdiction other than South Africa, we’re probably not the right choice.

It depends entirely on what it does, and anyone who gives you a number before understanding the scope is either padding to protect themselves or lowballing to win you. What we can tell you: a first version is usually a few months of work, not a few weeks, and not a year. The Blueprint replaces that guess with a real fixed number for R 12,500.

Because any number we published would be wrong for most people who read it. “An app” covers everything from a two-screen tool to a multi-tenant platform with payments. We publish the two prices we can stand behind — the Blueprint and the Efficiency Audit — and those produce the information needed to quote the rest accurately. There’s a longer version of this answer on /how-we-work/#pricing.

R 12,500, delivered in one to two weeks. You get a clickable prototype, a written specification, a fixed build quote across all three ways of working, and a POPIA and app store readiness checklist. All of it is yours to keep, including if you take it to a different developer.

R 8,500, delivered in about a week. You get a map of the process that’s costing you most, a prioritised list of what to automate first, a fixed quote for the top item, and an honest note where off-the-shelf software would solve it more cheaply.

No, and we’d rather explain why than quietly say yes. Crediting them would mean the entry price is really a deposit, which puts pressure on you to continue and on us to recommend continuing. Keeping them separate is what lets us tell you “don’t build this” without it costing us anything. The work is priced to stand on its own.

Fixed-price, invoiced in phases, with each phase agreed before it starts. Fixed-price services are payable before work begins. Project invoice terms are set out in the applicable quote or agreement. Payment by EFT or through Paystack — card details go to the gateway, never to us.

Not currently. Neevo isn’t a registered VAT vendor, so invoices carry no VAT. That changes once turnover crosses the compulsory registration threshold, and we’ll tell you before it affects a quote you’re holding.

Third-party costs that are genuinely yours: Apple and Google developer accounts, domain registration, third-party API or service subscriptions, and any paid licences your project needs. We disclose and agree these before incurring them, and we don’t mark them up.

We build in phases, and every phase ends with something that runs. If you stop, you stop owning working software and a repository you can hand to anyone — not a half-finished codebase. That’s a deliberate structural choice, and it’s the main reason we don’t do one big-bang delivery.

The phased structure effectively is one — you’re paying for a few weeks of work at a time rather than the whole project upfront. Beyond that, we’d rather reduce scope to fit a budget than stretch payments over a long period. A smaller thing you own outright beats a bigger thing you’re still paying off.

Build — we build it, you own it, you run it and launch it. Launch — we build it, take it live on both app stores, and keep it running; you own 100%. Partner — we carry most of the cost and work, and share in what it earns. Full comparison on /launch-your-app/#packages.

Build if you’re technical enough to run it yourself or you have someone who is. Launch if you want to own everything and carry none of the technical work — that’s most people. Partner if the idea is strong and capital is the blocker. The Blueprint prices all three for your specific idea, so you compare real numbers rather than guessing.

Most first versions are two to four months of build, plus two to four weeks for launch. App store review itself is usually days, but budget for at least one rejection and resubmission — nearly everyone gets one.

Yes, on Launch and Partner. On Build, the submissions are yours to handle and we’ll hand over everything you need. We tell you that upfront rather than at handover, because discovering it at handover is one of the three ways app projects die.

On Launch and Partner, we handle the rejection and resubmission at no extra cost. We can’t guarantee approval — nobody can, and be sceptical of anyone who says otherwise. What we can do is catch the common causes during the Blueprint, which is why the readiness checklist exists.

Not to talk to us. You will need one before you can hold an Apple or Google developer account properly, take payments, or sign a Partner agreement. Registering a private company through CIPC is inexpensive and quick, and we can point you to the process.

Yes, gladly, and you shouldn’t feel awkward asking. We also treat your idea as confidential from the first conversation whether or not anything is signed — that’s in our terms, not just our manners.

Honestly? Partly the contract, and partly that it would be a bad business decision. Ideas are cheap and execution is expensive; building your idea ourselves would mean funding it, marketing it and running it without the market knowledge you have. We commit in writing not to build a directly competing product. But the real protection is that we’d rather have a hundred clients than one app.

Usually not, and existing competitors are often a good sign — it means someone has proven people will pay for this. What matters is whether you can serve a specific group better than a general product does. That’s a question the Blueprint’s prototype-in-front-of-ten-people step answers far better than more thinking will.

No. We build, launch and run software. We’ll set up analytics so you can see what’s actually happening, and we’ll happily recommend people who do marketing well, but we’re not going to pretend to be an agency we’re not.

Sometimes. It depends on what state the code is in, and we can’t tell you without looking. We’d start with a paid technical review — usually cheaper than a Blueprint — that tells you honestly whether continuing or restarting is the better bet. Occasionally the answer is restart, and it’s better to hear that before you spend more.

It depends on what each side brings — capital, market access, domain knowledge, ongoing involvement — and it’s agreed in writing before any work starts. It may be revenue share or equity. We don’t publish a standard split because a standard split would be wrong for almost every deal.

Someone who knows their market far better than we do, an idea where software is genuinely the bottleneck, and a person who wants to stay involved. The last one matters most. Partner isn’t a way to outsource your startup — if you disappear after handover, it fails, and we’ve both wasted a year.

Because each one is real risk carried by a small studio. We’re funding the build, the infrastructure and the maintenance against uncertain revenue, so we can only run a few at a time. Saying no to most is what makes the ones we say yes to viable.

We both lose. You lose the time and market knowledge you put in; we lose the build cost and carry the infrastructure. That’s the trade — you’re exchanging upside for not carrying the upfront cost. The agreement sets out how either side exits and what happens to the code and the product if it winds down.

That’s a normal thing to want, and it’s dealt with in the agreement upfront rather than negotiated awkwardly once it’s succeeding. Get it written down at the start; it’s much cheaper than agreeing it later.

No, and if that’s the appeal it’s the wrong choice. Over a successful product’s life, a revenue share costs considerably more than paying for the build. Partner makes sense when you can’t raise the capital and would otherwise not build at all — not when you’d simply prefer not to spend it.

The signal isn’t frustration, it’s workarounds. If someone has to remember to send a spreadsheet, if two copies exist with different numbers in them, or if a new person can’t learn a process without sitting next to someone — that process lives in people’s heads and would probably live better in software. The Efficiency Audit is designed to answer this question specifically, including when the answer is no.

Often you should, and we’ll say so. Buy it when a product does 90% of what you need. Build when the remaining 10% is the part that makes your business different from your competitors, or when you’d have to reshape how you work to fit someone else’s product. The wrong choice is buying something that fits badly and then employing people to work around it.

Usually. Integrations with accounting packages, payment providers, email and calendar tools are common and normal. What matters is whether the existing system has a usable API — we check that during the Audit before promising anything.

That’s the risk that kills internal software, and it’s a design problem more than a technical one. We build around how people actually work rather than how the process is supposed to work on paper, which is why the Audit maps the exceptions and the workarounds rather than the official process. Software that ignores the exceptions gets abandoned within a month.

They will. That’s the main argument for custom software over a product — you can change it. Care Plans include an allowance of small changes each month, and larger changes are quoted as their own phase.

For a system built around how your team already works, training is usually short — an hour or two, plus written documentation. If a system needs a week of training, we’ve designed it wrong.

No. Some of the highest-value automation we could build is for very small businesses, because there’s nobody to absorb the admin. The honest caveat is that the cost has to make sense against the hours saved — the calculator on the homepage is a rough way to check that before you talk to us.

It’s the right question to ask. We don’t have a wall of logos, and we’d rather say that plainly than imply otherwise. What we do have is three products we’ve designed, built and run ourselves, so every technical problem a client project hits, we’ve hit first with our own money. And we’ve structured the work to reduce what you’re risking: fixed scope, fixed price, phased delivery, code you own from day one, and a small paid first step instead of a large leap of faith.

Your code lives in a repository on your accounts, documented well enough for another developer to pick up. That’s set up from the first commit, deliberately, because you shouldn’t have to bet your business on our survival. For Care Plan clients we also document the infrastructure so it can be handed to another provider without archaeology.

Yes, and we build assuming someone will. We use mainstream, widely-known technology rather than whatever is fashionable, and we document as we go. Choosing boring, well-understood tools is partly a quality decision and partly a hand-over decision.

For a Blueprint or an Audit, tell us within seven days if it doesn’t contain what we said it would, and we’ll fix it or refund you in full and you keep the work. For project work, each phase ends with a review, so problems surface within weeks rather than at the end. The full position is in the Refund & Cancellation Policy.

Deliberately few. Neevo is founder-led, which means you talk to the person writing the code and there’s no account manager translating in between — but it also means capacity is real and limited. If we’re full, we’ll tell you when we’re not rather than starting yours and being slow.

Not as a goal. If capacity constraints start hurting clients, we’d rather grow carefully than take on work we can’t do well. If that changes, existing clients hear it from us first.

We host applications and their data on South African infrastructure. Some supporting services may process limited information outside South Africa where permitted under POPIA; the current detail is set out in our Privacy Policy.

Yes. We’ll hand over the code, the deployment configuration and the documentation. Most clients would rather not, which is what the Care Plan is for, but it’s your choice and there’s no lock-in either way.

You do, on Build and Launch — code, data, accounts and intellectual property, on full payment. Partner projects have shared ownership defined in writing before work starts. We keep our own reusable tooling and general know-how, which is standard and set out in our terms.

Yes. We build cross-platform so one codebase serves both, which is meaningfully cheaper than building twice and is the right choice for almost every project we’d take on.

Encrypted connections, encryption at rest where appropriate, least-privilege access control, multi-factor authentication on admin accounts, patched systems, logging and regular backups. Care Plans include ongoing security patching, which matters more than the initial build — most breaches exploit known vulnerabilities in software nobody updated.

Operating system updates regularly break things. On Care Plans, keeping up with them is included. Without one, it’s your responsibility, and an app that stops working after an OS update is the most common way an unmaintained app dies.

We build the marketing site as part of Launch and Partner. We’re not a general web design studio and wouldn’t take on a brochure site on its own — there are people who do that better and cheaper.

Your application lives in a datacentre with backup power, so it stays up. What load shedding affects is your users’ ability to reach it and, occasionally, our working hours. Where it matters, we design for intermittent connectivity — offline tolerance and sync-when-reconnected — because that’s a real South African constraint rather than a theoretical one.

Partly, and the distinction matters. We build POPIA-aware software — consent handling, retention rules, access and deletion mechanisms, security measures. What we can’t do is be your compliance function: registering your Information Officer, writing your policies and answering data subject requests are your legal obligations. We’ll tell you exactly what those are during the Blueprint so nothing is a surprise.

For your app’s users, you’re the responsible party and we’re your operator, meaning we process data on your documented instructions. That’s a real legal distinction with different obligations attached, and it’s set out in a written operator agreement. For enquiries you send us about your own project, we’re the responsible party.

Yes — both POPIA and the app stores require one, and Apple and Google will reject a submission without a working link to it. On Launch and Partner we prepare one. On Build it’s yours, and the Blueprint’s readiness checklist tells you what it must cover.

It’s the strictest case under POPIA and needs parental consent under section 35. We’ve solved it for our own product GGFam, so it’s a familiar problem rather than a research project — but it does add real design work, and any quote will reflect that.

If you’re a registered private body, yes. The exemption for smaller businesses ended on 1 January 2022, so it applies to essentially every company and close corporation. It’s not expensive to produce, and the Information Regulator publishes a usable template.

Yes, always. Website terms don’t govern a development project — a signed services agreement and statement of work does, setting out scope, price, timeline, ownership and what happens if either side wants out. Nothing starts without one.

No. We’re software people, not lawyers. For anything beyond describing our own terms and implementation approach, we’ll suggest you get legal advice.

A monthly plan covering hosting, security patching, backups, uptime monitoring, operating system compatibility updates, a direct support channel, and an allowance of small changes each month. Software isn’t finished when it ships.

No. You can host and maintain it yourself and we’ll hand over everything you need. Most clients would rather not, which is fine — and if you cancel later, the handover offer still stands.

Monday to Friday, 08:00–17:00 South African time. Response times depend on severity and are set out in your agreement — something down in production is not the same as a cosmetic issue, and shouldn’t be treated the same way.

Monitoring alerts us to outages automatically. Whether we respond at 2am or at 8am depends on what you’ve contracted for, and it’s an honest conversation to have upfront rather than a discovery during your first incident. A genuine 24/7 commitment from a small studio would be a promise we couldn’t keep.

Email or your support channel. Small changes come out of your monthly allowance. Anything larger gets quoted as its own phase before we build it — never after.

Yes, with 30 days’ notice, effective at the end of the billing month. No penalty, no exit fee, no minimum term unless your agreement specifically says so. We’ll help you migrate at no charge for 30 days after cancellation. Full detail in the Refund & Cancellation Policy.

You get all of it — database exports, files, code, credentials, documentation, DNS. We’d rather you stayed because it’s working than because leaving is painful.