The data exists. Getting it into one place is the job.
Student information in one system, transportation in another, food service in a third, and a state reporting cycle that eats a week because somebody has to reconcile all three by hand.
Bought by K-12 districts and education service centers.
Held Eleven records fail validation and are named individually with the field at fault. Nothing is submitted until a person clears them.
What the work produces
- State reporting that runs itself
- Extracts built against the current specification, validated before submission, with the errors named rather than returned as a code.
- One student record, assembled
- Enrollment, attendance, transportation, meals and services pulled into one view without replacing the systems they live in.
- Parent-facing tools people open
- Built for somebody checking a bus on a phone at 6.40am, not for a demo.
- Reporting the board can read
- The numbers a trustee asks for, produced on demand rather than assembled the week before.
Also in this category: Student information system integrationState reporting and compliance extractsTransportation and routingFood service and eligibilityParent and staff portals
Limits
What we will not do.
Stated before a solicitation rather than after an award, because finding this out late is expensive for both of us.
- We do not replace your student information system. Districts rarely need that and it is a multi-year procurement, not a project.
- We do not touch grading or instruction. That is a different vendor category and a different kind of risk.
- State reporting specifications change. That is what the support arrangement is for, and we will tell you what it costs before you sign rather than after the specification moves.
Questions a buyer asks
Do you work with our existing SIS?
Yes, and that is usually the point. We build against whatever you run — Skyward, PowerSchool, Frontline, or something older — rather than asking you to move.
Can this be funded from a specific allotment?
That depends on the allotment and the work, and your business office will know better than we will. We can describe the scope in whatever terms the funding source needs.
What about student data privacy?
The system runs in the district’s own environment, so student data does not leave it. FERPA obligations stay where they are, and we sign whatever data agreement the district requires.
How do you contract with a public entity?
Through whatever vehicle the entity uses: direct award under the bid threshold, competitive solicitation, an interlocal or cooperative contract, or as a subcontractor to a prime. We will tell you which we are eligible for before you spend evaluation time on us.
Where does the software run?
In the entity’s own cloud accounts, under the entity’s own contracts. We are given scoped access during the build and it is revoked at handover. That keeps the data inside your perimeter and means nothing depends on us continuing to exist.
Who owns the code?
You do. Source is delivered to your repository under a license permitting unrestricted use, modification and resale, with documentation written for whoever inherits it. There are no seat licenses and nothing switches off if the relationship ends.
What about accessibility?
Anything public-facing is built to WCAG 2.1 AA and tested with a keyboard and a screen reader before handover, not after a complaint. Say in the solicitation if you need a VPAT and we will produce one.
What about records retention and open records?
Anything we build that holds public records is built assuming those records will be requested. That means exportable, searchable, and able to produce a defensible set for a request — designed in rather than added later.
Permitting and licensing Data and systems integration Records and document automation