What we shipped, fixed and wrote down
Public, dated, and without a marketing wrapper. Compliance changes appear in the same feed as code, including the ones that go against us, because a changelog that only carries good news is an announcements page. RSS lives at /changelog.rss.
| Date | Type | What changed |
|---|---|---|
| 2026-05-18 | Shipped | Open-source ParentSquare importer v1.4.2 Now handles the newer multi-file export format. Added a --validate flag that compares against source counts and exits non-zero on mismatch, so it drops into a CI pipeline or a district's own scripts without a wrapper. |
| 2026-05-05 | Documented | Master Agreement v2026.05 published Updated §11.2 change-of-control language to cover acquihires explicitly — the previous wording could have been read as applying only to an asset sale. Redline-friendly Word and PDF versions are available on request from the trust page. |
| 2026-04-22 | Trust | Texas SB 820 cybersecurity attestation drafted Filing in progress for Texas districts, effective for the 2026/27 school year. We intend to file directly with TEA on behalf of customer districts rather than handing you a form to fill in. |
| 2026-04-14 | Shipped | Roster sync withdraw guardrail A sync that would withdraw more than half of active records now aborts instead of executing, and records the run as aborted_guardrail. This is the truncated-CSV failure that turns one bad export into a district-wide messaging outage. The override is explicit and audit-logged. |
| 2026-04-01 | Documented | Sub-processor list trimmed Consolidating transactional email on Resend. Customer impact: none. We always notify 30 days before a sub-processor change; this is the public version of that notice. |
| 2026-03-21 | Trust | SOC 2 scope review complete Scope defined for a future audit. No audit has begun — it starts at our first district cutover. We publish this so that nobody reads 'scope review' as 'certified', which is a mistake we have watched buyers make with other vendors. |
Four categories only: Shipped (code a district can use), Fixed (a defect corrected), Documented (a contract, policy or artefact changed), Trust (compliance posture moved, in either direction). There is no "improvements and bug fixes" entry on this page, and there never will be.
The release window, and why it is May
Major releases ship in May, with professional-development packs attached, so that teachers and front-office staff learn a changed product over the summer instead of during a term. Between September and May we ship polish, defect fixes and documentation only. No surprise features land in October.
This is not a preference, it is a scheduling constraint most K-12 vendors ignore. A district's absorption capacity for change is close to zero between the first day of school and the last, and a feature that lands mid-year gets absorbed by whoever happens to notice it, which is usually nobody. Shipping the same feature in May means it arrives with materials, gets covered in August professional development, and is a familiar part of the tool by the time it matters. The cadence is wired into the product itself: the in-app "what's new" surface and the help centre's PD materials are keyed to the release window rather than to deploy dates.
The practical consequence for a buyer is that our roadmap dates are coarse and honest. When we say a capability ships in the May 2027 release, that is a real target with a real window attached, not a quarter that quietly slides. It also means that if something you need is missing today, the answer to "when" is usually "May", and you can plan a school year around that.
What gets an entry, and what does not
Four tags, and nothing else. Shipped means code a district could use. Fixed means a defect corrected, described in terms of what went wrong rather than what was patched. Documented means a contract, policy or procurement artefact changed — a redline to the master agreement is as material to a CTO as a feature, and usually more so. Trust means our compliance posture moved, in either direction.
What does not get an entry: dependency bumps, internal refactors, copy edits, and anything that would read as "improvements and bug fixes". If we cannot say what changed for a district in one sentence, it does not belong on a page a district reads.
The entry we would most like other vendors to copy is the SOC 2 one from 21 March 2026. It records that a scope review finished and that no audit has begun. It exists because "SOC 2 scope review complete" is the kind of phrase that gets repeated back as "SOC 2 certified" two conversations later, and the cheapest place to kill that misunderstanding is the changelog. The full current position is on the trust page, restated with a date.
Reading this as a buyer
A changelog is one of the few artefacts a vendor cannot easily fake for the length of an evaluation, which makes it worth reading properly. Three things to look for, in ours or anyone's:
- Do compliance items appear at all? Most vendor changelogs are feature-only. Contract, sub-processor and certification changes are the ones that affect a procurement file, and their absence usually means they are being communicated by account manager, one district at a time.
- Are there entries the vendor would rather not have written? Ours include a sub-processor list being trimmed and an audit that has not started. If every entry is a win, the feed is a marketing channel.
- Do the dates cluster sensibly against the school calendar? A vendor shipping major functional changes in November is telling you something about how much they think about your operating year.
On the 14 April entry, because it is the most useful one here. The roster withdraw guardrail aborts any sync that would withdraw more than half of active records. This is a defence against a specific, common and very expensive failure: a truncated CSV export — a job that timed out, a filter left applied, a partial SFTP drop — arrives looking valid, the platform faithfully withdraws every student not present in it, and by lunchtime a district cannot message thousands of families. Overriding the guardrail is possible, explicit, and audit-logged. Ask whichever vendor you are evaluating what happens to their platform if tonight's roster file arrives half empty.
Subscribing, and what happens next
The RSS feed is at /changelog.rss and carries the same entries as this page, with the tag in each item title. There is no email newsletter and no notification list, because a changelog does not need a growth channel attached to it.
Everything above dates from 15 March 2026; earlier history is available on request. The next material entries will be the ones nobody enjoys writing: the first production incident, the first sub-processor added under a district contract, and the date the SOC 2 observation window actually opens. When those happen they will appear here with the same tags, on the same page, at the same level of detail as the good news.
Questions people actually ask
How often does Kastr release?
Major releases ship in May with professional-development materials attached, so staff learn changes over the summer. September to May is polish, defect fixes and documentation only — no surprise features mid-term. The cadence is wired into the product's in-app release notes and help centre, not just into a policy page.
Why are compliance updates in the same feed as code?
Because to a district CTO a redline to the master agreement or a change to the sub-processor list is at least as material as a feature. Keeping them in one dated feed means a procurement file can be reconstructed from a public page rather than from an account manager's inbox.
Does Kastr have an RSS feed for the changelog?
Yes, at /changelog.rss, carrying the same entries as this page with the category tag in each item title. There is no email list attached to it.
What is the roster withdraw guardrail?
A sync that would withdraw more than half of a district's active records aborts instead of executing, and records the run as aborted_guardrail. It defends against the truncated-export failure where a partial roster file causes a platform to withdraw thousands of students and silently stop messaging their families. Overriding it is explicit and audit-logged.
How far back does the changelog go?
To 15 March 2026 on this page. Earlier history exists and is available on request — before that date there was not much worth a district's attention, and padding the list would defeat the point of publishing one.
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.