Internal AI Copilot MVP: What to Put in v1 and What to Cut

What "v1" means for an internal copilot

An internal AI copilot is a private assistant. It answers your team's questions from your company's own documents. It shows where each answer came from, and people only see what they're allowed to see. Most copilots use RAG (retrieval augmented generation). First the system loads your documents and splits them into short passages. When someone asks a question, it finds the most relevant passages. It sends those passages and the question to a language model, which writes the answer and cites its sources. Through all of this, it checks who is asking, so nobody gets answers from documents they shouldn't see. The key idea is one job. A copilot that tries to cover HR, sales, finance and support on day one takes longer to build and to test. It's also harder to trust. You can read more about how we approach AI builds on our AI MVPs page.

The scoping checklist: 7 decisions before any code

Answer these seven questions in writing. If you can't answer one, that part isn't ready for v1.

1. Who uses it first?

Pick one team. Sales, support, operations or onboarding make good first users because they ask the same questions again and again. Write down how many people are on that team and which of them will give feedback.

2. Which job does it do?

Ask that team for the 10 to 20 questions they really ask. Write them down word for word. Next to each one, write the correct answer and where it lives. This list does two things. It defines the scope. It also becomes your test set: if the copilot can't answer these questions well, it isn't ready.

3. Which source?

Look at where the answers to your test questions live. Usually most of them are in one place: a shared drive, a Notion space, a folder of PDFs. Start there. Every extra source means another connector, another login method and another sync. Add them once you know they're worth it.

4. Who can see what?

This is where scope tends to grow without anyone noticing. Copying the exact permissions for every document from another tool is the heaviest option. For v1, use one of these two:

• Open content only. Start with documents everyone can already see: the handbook, policies, product docs.
• A few access levels. Group documents into simple levels like all staff, managers and leadership.

5. Where do people ask?

Choose one interface. A web app is the simplest base. A Slack or Teams bot is a second interface with its own login and message format. Mobile is a third. Put the copilot where your first team already works, and only there.

6. What counts as a good answer?

Write down your rules before the build starts. A copilot that sounds confident without sources is a demo, not a tool. For most internal copilots, a good answer:

• Cites the document it came from.
• Says "I don't know" when the documents don't cover the question.
• Gets the answers in your test set right.

7. What admin do you need on day one?

Keep it to the minimum: add and remove users, add and remove documents, see a log of the questions asked. Dashboards, budgets per team, feedback review screens and audit exports can come later. Not sure how to answer these seven? Book a call. We'll go through them with you and mark what can wait for v2.

What to cut from v1

Here are the features founders most often want in v1, and when they usually make sense. Don't cut the last three items. Without them, people stop trusting the answers, and nobody uses an internal tool they don't trust. If some of the cut features are still on your list, our feature cost guides explain what each one adds to a build.

• Several data sources. Why it's tempting: "the answers are everywhere". In v1: cut. Add it when: your test questions keep pointing to a second source.
• Live sync. Why it's tempting: files change often. In v1: cut, upload by hand. Add it when: manual uploads become a weekly chore.
• Exact permissions per document. Why it's tempting: sensitive files exist. In v1: cut, use access levels. Add it when: a real access problem shows up.
• Slack or Teams bot. Why it's tempting: people live in chat. In v1: cut, web app first. Add it when: the web app is used and people ask for it.
• Mobile app. Why it's tempting: field teams. In v1: cut. Add it when: your first users work away from a desk.
• Self-hosted model. Why it's tempting: privacy worries. In v1: cut, read your provider's data terms. Add it when: a client contract or regulator requires it.
• Actions (send emails, update records). Why it's tempting: "make it an agent". In v1: cut. Add it when: answers are trusted and the action is clear.
• Usage dashboards. Why it's tempting: leadership wants numbers. In v1: cut, keep a question log. Add it when: several teams use it.
• Citations. Why it's tempting to skip: feels optional. In v1: keep. Always in v1.
• "I don't know" answers. Why it's tempting to skip: feels like a weakness. In v1: keep. Always in v1.
• Access control. Why it's tempting to skip: feels like extra work. In v1: keep, in its simplest form. Always in v1.

A hypothetical example: a narrow v1

Imagine a property management company that wants its staff to ask questions about lease terms. The wish list covers every lease, live sync with their property software, a Teams bot, and permissions copied from their file system. Here's what a narrow v1 could look like for a company like that. In v1:

• One team: the leasing staff.
• One job: answer questions about lease terms, like notice periods, renewal clauses and pet rules.
• One source: lease PDFs, uploaded by an admin.
• Two access levels: staff and managers.
• One interface: a web app with citations that link to the right page of the lease.
• A test set of 20 real questions from the leasing team.
• A simple admin view: users, documents, question log.

In v2, once v1 is used every week

This v1 is smaller, but it does the one thing the team needs. After that, the question log shows which v2 features people actually ask for. In v2:

• Live sync with the property software.
• A Teams bot.
• More teams, more document types.

Signs your v1 is still too big

Each of these makes the build longer and testing harder. They're also why a first version never ships. If you want a quick outside check on the idea itself, try our app idea validator. Go back to the checklist if:

• You can't name the first team.
• You have no written list of real questions.
• More than one source is "required".
• The copilot has to take actions as well as answer.
• You're planning three interfaces at once.

How we scope a copilot with you

Our MVP is Fixed at $3,460 for your app on the web, iOS and Android. For a copilot, we scope the v1 with you, then give you a fixed quote before we start. Bring your source, your first team and your list of questions. Book a call to scope your copilot's v1. Here's how it works:

• Scoping first. We go through the checklist above with you, using your source, your first team and your questions.
• Progress shown every week. You see the copilot take shape and test it with your own questions.
• Your code. It's 100% yours, on your GitHub.
• 2 weeks of fixes after launch. Your team uses it for real, and we fix what comes up.

How many data sources should a copilot v1 have?

One, in most cases. Choose the source that answers the most questions on your test list. Add more sources when your question log shows people asking about content that isn't there yet.

Should v1 be a Slack or Teams bot instead of a web app?

Only if your first team works almost entirely in that tool. Otherwise, start with a web app. It's one interface and one login, and it's easier to test citations and access levels there. Add the chat bot in v2.

Do I need a self-hosted model for a private assistant?

Usually not for v1. Read the business data terms of the model provider you plan to use, and check them against your security policy and client contracts. Self-hosting makes sense when a regulator, a contract or your own policy requires data to stay on your servers.

I already built a copilot prototype with an AI builder. What now?

Bring it to the call. Start with the same checklist: what job it does, which source it uses, and who can see what. Our AI prototype to production page explains how we take prototypes to production.