Low Code in Public Education Who Gets to Build

Ask a teacher what would make tomorrow's lesson easier, and the answer may be quite modest. A reading activity with familiar examples. A quiz they can adjust. A simple way for students to find the right information.

The teacher knows the problem. Finding someone to build the tool may take longer than the idea deserves.

Low-code platforms offer one possible route: educators can assemble applications from visual components, with less custom programming. That could bring classroom knowledge into the building process much earlier. We'd still need to check who can use the tool and who will look after it once it's working.

Let the person who knows the problem help shape the tool

A low-code platform provides reusable software parts for screens, forms and actions. Users connect and configure them rather than writing every part from scratch. More complex projects may still require code or specialist help.

For education, the appeal is practical. A teacher could participate directly in designing an activity and adjust it after seeing where students struggle.

The fit depends on the project and platform. Before choosing one, I'd check the features, learning effort and costs against a specific classroom need. “We can build apps” is an interesting possibility; “we can fix this problem” gives the project a purpose.

Start with something people can try

Consider a hypothetical public college where students keep asking when laboratories are open and which equipment they can use.

A student group speaks with classmates and lab staff, then builds a small prototype showing timings, equipment and a contact for questions. They use dummy records while testing the structure.

One student opens it on an older phone. Another struggles to read an instruction. Lab staff notice that the opening hours need a clearer update process.

Those observations give the team useful work to do. They can improve the screens and decide who maintains the information. If a clear page answers the question, an AI chat feature may add effort without helping the user.

Make participation possible during class

Potharalanka's low-code education paper considers opportunities alongside concerns about bias, privacy and fair access. It made me think about what participation requires after a platform becomes available.

Some students may have a device at home. Others may only get access during teaching hours. A beginner may need help understanding the visual interface even if it involves little coding.

In a classroom with shared computers, I'd schedule building time and rotate roles. Let students plan screens and logic on paper first, with instructions in language they understand.

Then observe what happens. If the same student controls the keyboard every week, the rest of the group may be contributing ideas without getting a chance to build. Adjust the activity while there's still time for everyone to practise.

Watch someone use it before calling it accessible

Automatic checks can identify some accessibility problems. A real person completing the task can reveal others.

Test on a small screen. Examine text size, contrast and button labels. Where relevant, include keyboard navigation and assistive technology with appropriate support.

Watch where the user pauses or asks for help. If they can't find the next step, explaining the intended design won't fix their experience. Change the design and try again.

This is useful learning for students too. Their explanation of why they changed a screen may show more understanding than the finished screen alone.

Give student data a clear purpose

Early classroom prototypes can often work with dummy records. There's little reason to begin by uploading attendance histories, marks or personal details when the group is still testing its idea.

If the institution later wants to introduce real records, examine access, permissions, retention and the provider's data terms. Assign responsibility for managing the application.

An AI feature that recommends learning activities or labels student performance needs particular attention. Educators should examine the basis for those suggestions and keep consequential decisions under appropriate human review.

One poor attempt at an activity shouldn't quietly become a lasting judgement about a learner.

Plan for the term after launch

Applications need care. Someone must update information, handle account issues and respond when the platform changes.

Before daily use, check subscription limits, export options and the cost of supporting more users. Understand whether the institution can recover its data and what moving elsewhere would involve.

Include these questions in the project itself. Students should get a chance to understand why software requires attention after the presentation is over.

I'd begin with one small pilot and a task people can complete. Collect feedback from users with different devices and levels of confidence, then review what improved and what still needs work.

A clearer understanding of the classroom problem is a useful result, even if the first app needs rebuilding.

Questions educators ask

Does low code remove the need for technical support?

It can make initial building easier. Complex logic, integrations, security and ongoing maintenance may still need specialist help.

Should every classroom tool include AI?

Add it when it serves a clear learning or practical purpose you can evaluate. Consider the checking and maintenance each additional feature will require.

What I read and what stayed with me

Lalitha Potharalanka's Low-Code Platforms in Public Education: Opportunities and Challenges for Equitable Access (2025), Journal of Computer Science and Technology Studies, 7(7), 237–243, prompted me to consider participation and ongoing care alongside ease of building. The college example and proposed pilot are my applications to an Indian education setting.

Read the supplied research or visit the publisher version.