01
Segment
Engineering teams of about 5–10. Either the whole startup, or one team inside a larger company. One engineer can try it alone. The aim is that every engineer on the team adds to the knowledge base, and from there the rest of the organization.
Open-source projects are not a segment. A public codebase is only a case study for checking retrieval.
02
Buyer and user
Bottom up
User: the engineer, then the rest of the team. They start on their own, on a repo they host. The first engineer gets others to add their own sessions.
The initial goal is usage, and validation that the problem is real and that a solution is needed. The later buyer is the startup or the company. The engineer is the user.
03
Problem
The how-to is worked out inside a coding session, and then the session ends. The next time it comes up, the same engineer, or a teammate, does it again.
Writing it down means stopping the work. Documentation falls behind, and it falls behind faster as coding agents increase the pace of shipping. Much of what happens, including meetings, is never written down. The know-how stays in someone’s head or in a private session. The specific ways a company works are not in the data the models were trained on.
Coding agents already have access to Slack, GitHub, and Jira, where the company describes how it works and how the product is built. Finding the correct information there is still difficult. Slack has no semantic search. If the agent does not know the exact words, and the engineer does not point to the thread, the agent will not find those messages. The same applies to tickets and to code. The agent might find them only by searching the whole repository, or the whole GitHub organization.
That search costs tokens. If the agent does not search, it proceeds on assumptions. A mistake becomes more likely, which costs again, or the mistake passes review and reaches production.
04
Value proposition
Sessions turn into know-how the agent can read the next time. First for the engineer who did the work, from things they keep repeating. Then for the rest of the team, once those engineers add theirs.
The agent reads that know-how instead of searching Slack, tickets, and the whole codebase to recover a how-to. The team shares one repository instead of asking a teammate or maintaining a wiki. One person can keep the repository on their own machine, so a trial does not require an account or approval.
Whether a single engineer receives value before the rest of the team adopts it has not been validated.
05
Positioning
Nucipal is a knowledge base for coding agents. Any agent can read it. It is not tied to one coding tool. The team hosts it. One engineer can keep it in a local git repository that does not have to be online. If others should read it and contribute, the repository can be online.
| Nucipal | Is the alternative to |
|---|---|
| Know-how taken from sessions, in a repo any agent reads | A session that is gone when it ends |
| The team adds to one repo | Asking a teammate, or a wiki that becomes outdated |
| Self-hosted, including a repo that stays on one machine | A tool that needs an account and someone to approve it |
06
Channel
We start with people we know. In parallel: direct outreach, forums and comments, and SEO and GEO. The project is open source, so it can be shared publicly.
Each channel is measured the same way: someone clones the project and tries it on their own work. For the close network and direct outreach, that person is someone we contacted. For forums, comments, SEO, and GEO, that person found it independently.
07
Conversion
Someone we know tries it on their own work. If they qualify as a fit, we ask them to clone it, try it, and report whether it was useful. If it is, a second engineer adds insights from his sessions to the same knowledge base. The rest of the team contributes, and adoption can then extend to the organization.
Customer profile
Jobs, pains, and gains
Get the agent through a how-to the team has already done, without digging up an old session or pulling another engineer off their work.
The answer lived in a session or in someone’s head, and it is not there the next time. Writing it down means falling behind. A startup may be unwilling to adopt another tool. A team inside a larger company may be unable to get the rest of the team to adopt it.
Know-how from sessions is available to the agent. A single engineer can receive that value before anyone else adopts it. Once every engineer contributes to the same repository, the next person does not have to solve the same how-to again.
Business model
One customer, one offer, one channel.
| Customer | An engineer, then a team of about 5–10, either a whole startup or a team inside a larger company. |
| Offer | Open source. They host it. Know-how lives in a git repo any agent can read. One person can keep that repo local. |
| Channel | Close network first. In parallel: direct outreach, forums and comments, SEO, and GEO. The repo is open source. |
| Relationship | Two founders. Both build. One spends more time on the conversations. |
| Revenue | Not a goal at this stage. The first goal is usage, and validation of the problem and the need. The later buyer is the startup or the company. Price is not set. |
| Cost | Hosting and model usage are paid by the user. Our cost is not yet defined. |
Design partners
No design partners are named. The previous list has been retired.
To define
Questions
- Which group do we approach first: a whole startup, or a team inside a larger company? This is undecided, and we do not yet have criteria for the choice.
- What result do we want within a bit less than three months: a larger company evaluating the product, stars, active use, or a case study? We have not chosen which of these to optimize for.
- How do we define “useful,” and what wording do we expect people who try the product to use when they confirm it?
- What qualifies someone as a fit to try the product?
- What is the first use case we recommend when someone tries it?
- Should we avoid very large companies whose purchasing goes through procurement? An engineer at such a company using the product, without the company paying, could still count as validation.