Five things we do that this market mostly will not.
A long feature list is not the same as a product that works. We picked a small number of things, wrote four of them into the contract, and published the list of what we refuse to build. Here is the reasoning, including the parts that cost us deals.
| We do not build | Why not | Use instead |
|---|---|---|
| District websites | You already have a website vendor, and a CMS is a different product with a different release rhythm. Trying to be both is how comms tools get slow. | Your existing web vendor |
| Social media autoposting | A solved problem with several good products in it, none of which need to be inside a student-data system. | Buffer, Hootsuite, or the platform's own scheduler |
| Payment and fee processing | Handling family money means PCI scope, chargebacks and refund disputes inside a messaging tool. Specialist vendors are also cheaper per transaction. | Your district's payment vendor |
| An AI assistant, sidekick or agent | Machine translation is the one place a model earns its keep, and you read its output before anything sends. Everywhere else Kastr is deterministic plumbing you can audit. | The API and MCP server, driven by whatever model you already trust |
| A tutoring or services marketplace | We will not take a cut of services routed to your families. That is the same conflict of interest as family monetisation with a different label. | Your own vetted provider list |
| Parent subscriptions of any kind | Clause §9.4 forbids it. If our revenue can come from your families, every product decision quietly bends toward them. | Nothing. This one has no substitute and that is the point. |
| Premium, Pro and Enterprise tiers | Tiers exist to make the published price meaningless. One price, every feature, or the published price is theatre. | — |
| An insights dashboard you look at twice | Engagement scores invite comparison between schools that the underlying data cannot support. | Plain delivery records, and the API if you want your own analysis |
| Behaviour points and classroom scoring | A genuinely different category with a genuine ethical critique attached. Not our space and not our expertise. | A specialist product, chosen deliberately |
If you need two or more rows from this table, we are the wrong vendor, and we would rather you know that in week one of an evaluation than month four of an implementation.
01. Locked pricing, written into the agreement
Most K-12 communication vendors escalate renewal pricing year over year, and the escalation is rarely capped in writing. The price you sign for in 2026 is the price you pay in 2028: fixed for the 36-month initial term, with year four and beyond capped at the lesser of CPI-U or 5%. It is clause §3.2 of the master agreement, not a press release, and any feature we ship during the locked period is included at no extra charge.
What to look for: a vendor who will not put their maximum annual increase in the agreement as a number. There is a reason, and it is not a legal one.
02. Your data is exportable on any day of the term
Most vendors treat portability as part of their exit motion rather than their normal operations. Clause §7.1 gives you the right to export everything — messages, forms, audit logs, family contact records — at any time, in a machine-readable format, without notice and without fee.
Precision matters here more than enthusiasm. That is a contract right today, executed by us on request, same day. Self-serve export tooling ships with the May 2027 release, and until it does we are not going to describe it as one click. The ParentSquare importer, separately, is already MIT-licensed and public, so at least one piece of the portability story is code you can read rather than a clause you would have to enforce.
What to look for: vendors who only demonstrate the export flow once you are already leaving.
03. No family monetisation, ever
Some models in this category depend on a second revenue stream from your community: subscription fees inside a parent app, processing cuts on family payments, marketplace commissions on services routed to households. None of those are available to us, because clause §9.4 forbids all of them.
This is not a values statement, it is a structural one. If a vendor can earn money from your families, then every product decision — notification frequency, what the app shows on open, where the upgrade prompt sits — has a second constituency, and it is not the district. Free-to-district platforms are genuinely free to the district. The cost has been moved to household budgets, and the families most likely to pay are not evenly distributed across your enrolment.
What to look for: vendors whose unit economics require your families to buy something. Ask for the answer in writing.
04. One narrow use of AI, not a brand applied to everything
There is no AI Sidekick, no AI Newsletter Wizard and no AI Insights dashboard. There is exactly one place a model runs in Kastr: translation, through DeepL, because machine translation is a genuinely solved problem worth paying for — and you read its output in preview before anything sends.
Everything else is deterministic plumbing you can audit: a queue that claims work with SKIP LOCKED, idempotency keyed on broadcast, person and channel, quiet-hours logic with a documented default window, SMS-to-voice failover on terminal failure. None of that is exciting and all of it is inspectable, which is the correct trade for a system that tells 14,000 families whether school is open.
The place we do lean on models is the opposite of a chatbot: a native MCP server exposing typed tools over the same API, the same row-level security and the same audit log, with sends gated on a human. Bring your own model. See how that works.
What to look for: products that add "AI" to every feature name, then quietly remove half of them in the next major version.
05. Five capabilities, shipped properly
Broadcast. Two-way conversations. Translation. Forms. Community groups. That is the product. The composer is fast because the rest of the application stays out of its way, and the front-office staff who send twenty messages a week are the users we optimise for — not administrators, and not the person running the evaluation.
The corollary is that our feature table has gaps a competitor will point at, and they will be right to. No single sign-on: magic link is the only authentication we have built. No attachments, photos or video. No mobile push. No SOC 2 report, no customer references, no auto-notice engine firing rules on its own. Read the head-to-head, which puts our losses in the same table as our wins.
What to look for: pricing pages that hide twelve modules behind four tiers and three add-ons. The modules are how the published price stops meaning anything.
Bragging about what you have is the easy version
The table at the top of this page is the harder one. It exists because the most expensive mistake a district makes is not choosing a weaker product — it is choosing a product whose roadmap points somewhere else. A vendor building a website CMS, a payments rail and an attendance analytics suite is not going to spend next year making the composer faster.
So the refusals are published, dated and specific, and if two or more of those rows are requirements for you, we are the wrong vendor. That is a fine outcome. It is a much better outcome than month four of an implementation.
The four questions that separate a shortlist faster than a feature matrix. What is your maximum annual increase, written into the agreement as a number? Can we export everything today, not on exit? Do you earn revenue from our families in any form? And if you are acquired, what are our rights? Four sentences, four vendors, one afternoon.
Questions people actually ask
What does Kastr deliberately not build?
District websites, social autoposting, payment processing, an AI assistant, a tutoring marketplace, parent subscriptions, feature tiers, an engagement-score dashboard and behaviour-points scoring. Each refusal has a reason and a suggested alternative in the table above. These are scope decisions rather than roadmap items, which is why they are published rather than mentioned on a call.
Is Kastr actually cheaper, or just cheaper looking?
We cannot answer that against a specific vendor because most of this category does not publish a price. What we can do is remove the ambiguity from our side: $3.50, $3.25 or $3.00 per student per year by enrolment, one tier, everything included, fixed for 36 months and capped after that. Convert your current invoice to per student per year, multiply by three, and the comparison takes about a minute.
Why should we trust a pre-launch vendor with district communications?
Cautiously, and with the gaps in front of you. We have no customers, no SOC 2 report and no reference calls, and if your process requires those then this is not your cycle. What we can put in front of you is code: cross-tenant isolation tested in CI against real Postgres, an append-only hash-chained audit log, an MIT-licensed importer you can run yourself, and a contract whose exit terms we wrote before we had anything to lose by writing them.
Does Kastr use AI to write messages?
No. There is no draft assist and no generated content anywhere in the send path. The single use of a model is DeepL translation, and you preview every language before the message goes out. If you want a model in the loop, the MCP server exposes typed tools over the same API and audit log, with the send held for human approval — your model, your prompt, our guardrails.
One price. Every feature. Locked for three years.
$3.50 per student per year under 5,000 students. No tiers, no add-on modules, no per-message fees. Published on the site because you should not have to book a call to learn a price.