Turning School Software Subscriptions into Small Tools

A working screen is no longer the hard part

Small operational tools can now be tested without building an entire software product. Peninsula School District in Washington State is one example: it serves 9,015 students across 17 schools, from kindergarten through high school. That scale means it is not a one-school experiment; it is an organisation that must operate tools used across multiple schools. Its student and school counts are published by the US National Center for Education Statistics.

The district’s research lead, who had no coding experience, built a programme prototype using an AI-assisted development approach. It took about three weeks to create a working education prototype. Crucially, those three weeks were not the time required to build financial-reporting functionality.

Financial reporting was a separate case. With the underlying environment already in place, the district recreated part of the financial-reporting functionality of a product that cost US$75,000 per year, or about KRW 104 million at the exchange rate used at the time, in roughly 45 minutes. It has not disclosed which reports from which product were replaced, or the total time spent on testing and security review. The 45 minutes should therefore not be treated as the total development time.

In the three weeks before publication, the district cancelled existing contracts worth about US$100,000, or roughly KRW 139 million. Its chief information officer estimated that it had saved or avoided US$315,000 to US$325,000 in software spending, or about KRW 440 million to KRW 450 million. This is the district’s own estimate, not a confirmed saving that includes long-term operating costs.

What the district wants to recreate is not the entire core system that manages student rosters, grades, and attendance. It is starting with bounded tasks such as simple reports, purchase requests, and electronic signatures. The chief information officer also acknowledged that the district is unusual because of his extensive computing experience. Outside experts noted that login, permissions, data deletion, security review, and ongoing fixes are harder than creating a prototype. (EdWeek Market Brief)

Smaller workflows can change first

Consider the administrative manager of a middle school in Korea with 900 students and 70 staff members. Each month, they export budget data from an existing accounting system, split it into files for facilities, teaching materials, and educational activities, then send those files to department heads. They merge the returned revisions and call people to resolve rows where the numbers do not match.

The problem is not one formula. Departments use different category names. Old figures remain when someone copies last month’s file. Time is lost finding which file is the final version. Buying an outside product can also mean renewing an annual contract that bundles many features just to get one report.

The first attempt can now be smaller. If the administrator describes the required report format and approval order, a staff member can test a prototype within weeks: upload a file, flag errors, and download a final report. Starting with copied data that excludes personal information, rather than directly connecting to the accounting system, means a failed test does not disrupt existing work.

If the result is useful, the next step is staff login and role-based permissions. The administrator can see all budgets, while a department head sees only their own department. The tool can record who made each change and when. Only after that should the school consider an automated connection that pulls data from the existing accounting system.

People still make the decisions. Someone must decide which category receives a misclassified expense, whether to allow an exception for an over-budget item, and whether to approve the final report. The tool reduces copying and missing-item checks; it does not replace the accountable person.

The constraints are also clear. Once student or staff information enters the tool, the school must decide who can see it, when it will be deleted, and who takes over when the responsible staff member transfers. If a connected accounting system or login method changes, the tool must be tested again. The time spent maintaining it over years may exceed the time spent building it initially.

That is why the ability to make screens quickly is difficult to defend on its own. Harder-to-copy assets are data that reconciles each school’s different categories, approval relationships between education offices and schools, a record of operating without incidents, and a distribution route that keeps the tool in use when staff change. Trust is the strongest of these assets. As permission data and institutional relationships accumulate, that trust becomes harder to replicate. (Peninsula School District AI)

Other education systems built the operating foundation first

Memphis-Shelby County Schools in the United States serves about 110,000 students across 214 campuses. Its internal strategic-planning team used Microsoft tools for rapidly assembling screens and automation to build a student behaviour-intervention record system, then deployed it to 550 users including counsellors and behaviour specialists.

It stored student data in one place, limited what people could view based on their role, and added an extra verification step at login. The district and supplier said the system reduced operating costs by about US$300,000 compared with the previous product and was expanded to all schools. Because those figures appear in a supplier customer story, they need independent verification. The central lesson is that a shared data store and permission management came before the screen. (Microsoft customer story)

At the other end is Ultranet in Victoria, Australia. The state government tried to build a shared teaching and assessment environment for all public schools at once. Its initial announced budget was AUD 60.5 million. The Victorian Auditor-General estimated total costs of AUD 180 million by June 2013, or about KRW 177.7 billion using the exchange-rate basis at the time.

The project entered operation before its functionality was complete, and its procurement and benefit validation also had problems. Use ended in late 2013. Rather than testing and expanding small workflows, changing every function at once can make it difficult to control not only build costs but also training, support, data migration, and local adoption costs. (Victorian Auditor-General)

Four things you could build from this

1. A subscription replacement finder. A service for education-office staff who manage workflow-tool contracts across several schools. Before renewal, it shows usage, overlapping features, personal data handled, and the difficulty of replacement. Now that small reports can be tested in-house, its first screen should rank near-renewal contracts by how easily they can be replaced.

2. A school-tool safety test lab. A service that helps teachers who have built attendance-support or counselling-scheduling tools without coding experience test them with dummy data before deploying them to real students. Permissions and deletion rules block projects more often than prototype creation, so the first screen should ask what information will be collected, who will use it, how long it will be kept, and whether it will be shared externally.

3. An education login and data-connection intermediary. A service for vendors or internal education-office teams building small school tools, helping them connect existing work-portal logins and school data within defined limits. Screens are easy to copy, but institution-specific approvals and connection experience take time to build. The first screen should use arrows to show what data moves from which system to where, and who can see it.

4. A school-tool handover vault. A service that manages the owner, review date, connected systems, recovery method, and retirement date for tools made by teachers or staff. Maintenance problems begin when a creator transfers or an outside system changes, so the first screen should show warnings for tools with no assigned owner or no recent test record.

What to check today

Ask an administrative manager or education-office IT staff member for a 30-minute call and ask them to show you one workflow tool they renewed recently. A small replacement tool may be worth testing if that tool has one repeated weekly function, requires files to be moved more than once to produce the same result, and can first be tested with data that excludes personal information.

Why this matters where you are

Check a recently renewed workflow subscription in your own education organisation for repeated tasks, overlapping features, and the personal data it handles. The specific systems and approval relationships will differ by market, but the operating work described here—permissions, deletion, maintenance, and handover—remains separate from making a prototype screen.