Behind ScaffoldSync: Building the Tool I Wished Existed
- Akaya
- 2 days ago
- 5 min read
In my last post, I wrote about the advantages of no-code and low-code (NCLC) technology. I talked about how these tools are democratizing development, closing skill gaps in Learning & Development (L&D), and giving educators the power to build highly personalized tools without needing a computer science degree.
But philosophy is only as good as its practical application.
Shortly after researching NCLC technologies, I decided to use them to automate my heavy workload. As an overworked special education teacher, I was frustrated by the lack of online resources that exactly matched the wording of my students' IEPs. As a result of this lack of resources, I often spent a good portion of my time and free time creating specialized resources for my students. I knew there had to be another way of going about this.
That's when I built ScaffoldSync—an AI-driven assistant built entirely on a no-code framework that saves me and other special education teachers hours of manually creating IEP resources for 10+ students. The results are specially designed resources that can be used for progress monitoring of IEP goals, independent work, and 1:1 and small-group work. Here is a behind-the-scenes look at why I built it, how it works under the hood, and how NCLC technology made it possible.
The Problem: The High Cost of Heavy Workloads
Not only did I build this tool for myself, but also for other special education teachers who were tired of spending what little free time they had on resource generation. As special education teachers, we are masters of personalization, but we are consistently buried under paperwork. When a student has an IEP, they are legally entitled to specific accommodations, modifications, and scaffolded materials. For example, if the class is reading a complex historical text, the text will likely need to be chunked into smaller, more manageable pieces, a visual schedule may need to be created, and/or comprehension questions for varying reading profiles will need to be made. While all of this is easy to plan, the execution is exhausting.
I wanted to build a solution that would let me type in a student's actual IEP goal and get back a resource that already matched it—not a generic worksheet I'd have to chop up and relabel after the fact. Something that knew the difference between a goal measured "with 80% accuracy across 3 trials" and one measured "for a duration of 10 minutes," and could automatically build both the activity and the correct data sheet around that distinction. That's the gap I built ScaffoldSync to close.
Teaching an AI to Think Like a Special Educator
The engine behind ScaffoldSync is Claude, but a powerful model on its own doesn't know what "appropriately scaffolded" means for a specific student. It will happily generate something that sounds right and is completely unusable in an actual classroom. So instead of writing a single prompt and hoping for the best, I built a structured system prompt using XML tags — essentially giving the AI clearly labeled sections for student complexity level, the exact IEP goal language, and the baseline data, instead of letting it guess at what mattered.
Think of it like the difference between handing a paraprofessional a vague instruction — "make this easier" — versus a detailed protocol that tells them exactly what "easier" means for this student, on this skill, at this moment. The XML structure prevents the AI from generating content that has nothing to do with the actual student in front of it.
One Tool, Three Kinds of Resources
Not every IEP goal calls for the same kind of practice, and that was my biggest complaint about the worksheets I found online. They assumed one format fit every use case. So ScaffoldSync isn't a one-button worksheet generator. It has a Resource Type selector that reconfigures what the AI builds: independent practice for a student working solo, an interactive small-group activity for pull-out time, or a progress-monitoring tool for tracking a goal over time. Same student data, same engine, three completely different outputs depending on what the moment actually calls for.
The Real Win: Solving the Paperwork, Not Just the Worksheet
Here's the part of ScaffoldSync I'm most proud of, and it's the part that doesn't show up if you only look at the worksheet itself: the data tracking table. Every IEP goal must be legally required to be measured — by accuracy, frequency, or duration — and the tracking sheet must match. Teachers don't just need the activity; we need proof that it's tied to progress toward the goal, in the right format, or it doesn't hold up.
So I built a data-tracking logic layer that reads the goal type and automatically generates the corresponding table in the final document. No second tool, no separate template I have to dig up and reformat. The compliance piece (and the part that actually takes up the most time and stress) is handled in the same 30 seconds as the resource itself.
From AI Draft to a Document I'd Actually Print
The last piece was formatting. An AI can write great content and still hand it back to you as a wall of plain text you then have to copy into Word, fix the spacing on, and format from scratch — which defeats the entire purpose. I engineered a pipeline that takes the AI's raw output and runs it straight into a document-generation step, so what comes out the other end is a polished, branded, ready-to-print PDF. No manual formatting step standing between me and a resource I can hand a student.
The Impact: Hours Back, Compliance Built In
What used to take me 45 minutes (finding a base resource, rewriting it to match a goal, building a tracking sheet, formatting everything) now takes about 30 seconds. And it's not just time. It's the difference between every student getting a resource that's actually written for them, in language that matches their IEP, with compliance baked in instead of bolted on at the end.
I didn't build ScaffoldSync to prove a point about no-code technology. I built it because I was tired and wanted my time back. But it turned out to be the clearest example I have of what I meant in my last post — that NCLC tools don't just lower the barrier to building software. They let the people closest to a problem build the exact solution they actually need.
Comments