StepReady: tender proposal

DSS2026/RFQ/0210

1. Cover

Prices are given separately in the quotation. This document contains none.

2. Executive summary

The brief asks for a simple web application on a 10–11 inch tablet at a packing workstation, so that students can start, continue, check, complete and hand over tasks with fewer reminders from an adult, while still asking for clarification, requesting help and reporting when they finish.

StepReady does this. It shows one photo and one short instruction at a time, from TODAY to NEXT. Staff create, edit, copy and remove tasks themselves behind a PIN, with no programming. Everything stays on the tablet, and it works offline after the first load. A working prototype is live now, so DSS staff can try it before deciding.

3. Our understanding of the requirement

The brief states its purpose as a simple web application for "a 10–11-inch tablet mounted at a packing workstation". The learner moves through a fixed six-stage sequence, one screen at a time:

TODAY → NOW → HOW → CHECK → DONE → NEXT

• Today shows the work planned for the day.
• Now shows the task to start.
• How presents one instruction at a time using a short sentence and a photograph.
• Check provides a short checklist for checking the completed work.
• Done reminds the learner to report that the task is complete.
• Next shows the next scheduled task.

The interface calls for large buttons, clear photographs, short instructions and minimal distractions. Employers and trainers must be able to create and update tasks without programming knowledge. The worked example is "Packing One Parcel" (five steps, four checks, a reporting phrase).

We read the aim as reducing adult prompts, not removing the adult. The student should act alone where they can, and ask for help easily where they cannot.

4. Proposed solution

4.1 The six stages

A read-only stage bar on every student screen shows where the student is (src/components/StudentLayout.tsx). The student sequence is a state machine in src/state/appState.ts, so there is nothing to mistype or bookmark.

4.2 Independence and help-seeking supports

Each support is tied to one verb in the brief's purpose and replaces a specific adult prompt. A support that did not map to a verb was not built. None adds a second main action or blocks the sequence, except the staff check, which staff switch on per task.

Calm chimes and short spoken encouragement are on by default and staff can switch each off (src/components/FeedbackSettingsPanel.tsx, src/lib/sound.ts, src/content/encouragement.ts). Every spoken phrase also appears as a short text message. There are no points, badges, streaks, confetti or countdown timers.

Help and completion signals are shown on the tablet only. Nothing is sent to another device and nothing is logged.

4.3 The seven staff functions

Staff open a PIN-protected section from TODAY (src/screens/PinScreen.tsx). A wrong PIN shakes and clears. No code or files are involved.

Staff also control sound, encouragement, read-aloud and nudge settings (src/components/SoundSettings.tsx, src/components/FeedbackSettingsPanel.tsx), and the staff check and materials list per task.

4.4 Included in delivery (not yet in the prototype)

The items below are not live today. We will build them and test them as part of delivery.

• NOW / NEXT / LATER labels on TODAY, as in the page-2 example.
• STAFF lock at the top right, as in the page-2 example. In the prototype the STAFF link is at the bottom left of TODAY.
• Android tablet test project. The app is built for Android Chrome. The automated suite currently runs WebKit iPad viewports. We will add a Chromium Android-tablet project.
• The trainer's real tasks and photographs, replacing the demonstration content.
• Rehearsal on the school's own tablets. Sign-off on a physical iPad is prepared (docs/IPAD_SIGNOFF.md) but has not been run.

5. Compliance table

Status: Live means it exists in the prototype now and the evidence is named. Included in delivery means we will build it, as listed in 4.4. Live URL: https://stepready.skubbsmate.com. Test files are in e2e/ and src/.

6. Technical approach

• Progressive Web App. React 18, Vite and TypeScript, built to static files. It installs to the home screen and opens fullscreen.
• Offline after the first load. A service worker precaches the app, photos and voice clips (vite-plugin-pwa). e2e/demo.spec.ts loads once, goes offline, reloads and completes a task.
• On-device storage. Task templates, photos, schedule and progress live in the tablet's IndexedDB (Dexie). Photos are resized to 1200 px at most before storage.
• No accounts, no server, no tracking. There is no backend, no API call and no analytics. Help requests and completion times are not recorded anywhere.
• Devices. A 10–11 inch tablet in landscape: iPad in Safari, and Android tablet in Chrome. See 4.4 for the Android test project.
• Personal data. No personal data leaves the tablet, which keeps PDPA exposure small. The app holds no student names or accounts. We have not made a formal PDPA assessment for the school.
• Sound and speech. Chimes are produced on the device. Encouragement uses short pre-recorded clips bundled with the app. Read-aloud of staff-written text uses the tablet's own voice.
• Content generation. Seed photos and clips were generated at build time with Cloudflare Workers AI and reviewed by a person. The running app never calls an AI service.
• Hosting. Static files on Cloudflare Pages over HTTPS. Backups are a JSON file staff keep.

7. Live prototype

Open the app on an iPad in Safari, let it load once, then use Share → Add to Home Screen. To restore the demonstration content, clear the site data or re-add the icon. The demo page's Restart button clears this browser's StepReady data, so use a browser that holds no real trial data. A ten-step demo script is in README.md.

8. Delivery plan and timeline

Weeks run from the award date.

The timeline assumes the school supplies tablets, trainer time and photo access in weeks 1–2.

9. Testing and acceptance

• Automated tests. Unit and component tests (Vitest) sit beside the code in src/ and cover the learner sequence, BACK, help, the CHECK gate, copy, archive, reset and resume, and backup. Playwright end-to-end tests in e2e/ currently pass for the PIN, creating and previewing a task, arranging the day, reset, the NOW materials list, encouragement settings, backup and restore, and the offline run at both iPad viewports. The remaining end-to-end specs (the full demo script, BACK on step 1, template copy, and the 64 px screen audit) are being brought in line with the current build and will all pass before delivery.
• Traceability. docs/ITQ_COMPLIANCE.md maps each requirement to code and tests. We will keep it current, and add the purpose statement and the new items in 4.4.
• Real-tablet sign-off. A written checklist (docs/IPAD_SIGNOFF.md) is run on a physical tablet at rehearsal, covering the demo script, offline use, sounds and read-aloud. The result is recorded and given to the school.
• Acceptance. The school accepts when the rehearsal checklist passes on its tablet, the trainer has created and previewed a task of their own, and a backup restores correctly.

10. Training, handover and support

• Training. One hands-on session for trainers (about 90 minutes), using their own task. A one-page quick guide for staff covers the seven functions.
• Handover pack. The static build as stepready-prototype.zip, a README, the hosted URL, the backup file of the configured tasks, and the test and sign-off records.
• Support. The supplier contact named in section 1 answers questions by email during the delivery period. Fixes to defects found against this proposal are made at no extra charge. Ongoing support terms are in the quotation.
• Updates. When a new version is deployed, a tablet picks it up on its next online load. Staff should take a backup before any update.

11. Assumptions, limits and exclusions

• No alerts to other devices. The help card and the handover phrase appear on the tablet only. Staff are not notified remotely.
• No cloud sync, no multiple students. Each tablet holds its own data for one student's flow. Data is moved between tablets by Export JSON and Restore.
• Fixed staff PIN. The PIN is 1234 in this version. There are no staff accounts. It deters casual access and is not a security control.
• Device lock. A web app cannot lock the whole tablet. We recommend iPadOS Guided Access (or Android screen pinning) to keep a student in the app.
• Browser storage. iOS may clear stored data for sites left unused for a long time. Staff should take regular backups.
• Photos. The demonstration photos are AI-generated to look like a Singapore workstation. Real photos from the trainer are used in delivery.
• Voice. Read-aloud uses the tablet's own voice, so it sounds different on iPad and Android.
• Out of scope. Real authentication, analytics, drag-and-drop ordering, more than one language, video, and hard deletion of templates (Remove archives).
• Assumptions. The school supplies the tablets, a stable first-load network connection, and trainer time for the photos and task content.

12. Later-phase options

These are optional, separate from this proposal, and not priced here.

• Cloud sync so several tablets share task templates.
• Staff accounts to replace the fixed PIN.
• Multiple students, with each student's own progress.

13. Company profile and track record

StepReady is submitted by The Support Station Private Limited, a Singapore-based software team. We are not a special-education provider. We read this specification, understood why existing task-prompting tools fail it, and built a solution from the brief.

What we do. Since 2014 we have delivered custom web and mobile applications, user-experience design and hosted platforms for government-linked organisations, national membership associations, healthcare providers and social-service clients. Our core capability is building applications that non-technical users administer themselves — content management, task configuration and day-to-day setup without a developer. That is exactly what this tender needs: a staff admin panel a vocational trainer can run without programming knowledge. Our team of roughly 40 people — delivery, UI/UX, engineering, QA, DevOps and account management — is based in Singapore.

Why this maps to the brief.

• Accessible UI/UX. Our designers work to WCAG 2.1 AA in production. For StepReady, accessibility is the primary design constraint, not a checklist: large touch targets, high-contrast typography, one action per screen and photos before text.
• Offline-first browser apps. The brief's core requirement — a browser app that runs fully offline on school-managed iPads with no mandatory cloud subscription — is met with a Progressive Web App (React 18, TypeScript, IndexedDB storage, service-worker offline).
• No-code staff administration. We have built content-management interfaces that non-technical operators use daily. The StepReady staff panel (task templates, photo upload, day scheduling, backup/restore) applies the same approach.
• Source-code handover, no lock-in. We routinely hand over complete source, project files and deployment assets at completion. DSS or any appointed third party may maintain or extend the application afterwards, with no licence restriction and no subscription required for continued use.

Security and compliance. PDPA-aligned handling (no student data leaves the device unless staff export it), OWASP ASVS L2-aligned development practice, WCAG 2.1 AA interfaces, and Singapore data residency for any optional cloud components.

Track record — selected relevant projects.

We have delivered accessible applications for larger membership bodies than this one. This engagement is smaller in scale and, in our view, more important to get right.

14. Project team

All members below are employees of The Support Station Private Limited and are available for the engagement. No subcontractors are proposed. The Managing Director is the authorised signatory and the primary escalation contact for DSS throughout. If a team member becomes unavailable, we maintain a bench of full-stack developers and designers who can be onboarded without loss of knowledge, since all project assets and the codebase are held in our managed environment.

Huang Zhongying (Zave) — Project Director. Managing Director of The Support Station since 2014; Certified Scrum Master and designated Data Protection Officer. Accountable for delivery quality, DSS stakeholder engagement and escalation. Has overseen delivery across government-linked, healthcare and social-service clients, including the HomeTeamNS OneHome and SAFRA KidzAmaze platforms.

Low Ee Chiang — Solution Architect / DevOps Lead. Defines the StepReady architecture — offline-first PWA structure, IndexedDB schema, service worker and iPad deployment — and owns the build pipeline and security/PDPA data-handling design. Lead architect across the company's application portfolio; specialises in offline-capable PWAs, CDN/static-site deployment and OWASP-aligned security.

Teo Yi Ki — Project Manager / Scrum Master. Day-to-day project management and the primary point of contact for DSS on scheduling, milestone sign-off and documentation. Coordinates UAT with non-technical client stakeholders: plain-language test scripts, feedback sessions, defect logs tracked to sign-off.

Aaron Briones — Technical Lead / Senior Full-Stack Engineer. Leads the StepReady build — React 18 component architecture, IndexedDB data layer, service-worker offline, the staff admin panel and student workflow logic — and owns code quality and the definition of done. 14+ years full-stack; technical lead on tablet-based kiosk and multi-role platforms.

Aung Khant Zaw — Senior Full-Stack Developer. Implements the student-facing screens (TODAY through NEXT), the HELP overlay, and photo display and navigation; contributes staff-panel features including template forms, day scheduling and backup/restore. Experienced in React 18/TypeScript, IndexedDB and in-browser image handling.

Vea Parale — UI/UX Designer & Developer. Leads the design for all student screens and the staff panel, runs the design review with DSS, and implements the front-end layout to match. Practical WCAG 2.1 AA experience, and design of kiosk-mode, tablet-first interfaces operable without reading instruction text.

Sumegha Chinigepalli — QA Tester. Writes the functional and UAT test plans for DSS staff, runs testing on school-managed iPads (Safari and Chrome) across all screens and admin functions, and manages the defect log through to rectification. Prepares plain-language UAT scripts a vocational trainer can execute without technical knowledge.

Quotation SR-Q-2026-001

Every figure or term marked DRAFT – owner to confirm is a recommended default that the owner has not yet confirmed. The line items are held in src/proposal/quote.json, which the proposal page and the e2e check use, so the numbers below and on the page come from one set.

Header

<!--QUOTE-->

Payment milestones

DRAFT – owner to confirm. Invoices are payable within 30 days.

Timeline

Weeks run from the award date. The full plan is in docs/PROPOSAL.md section 8 (Delivery plan and timeline). DRAFT – owner to confirm.

The timeline assumes the school supplies tablets, trainer time and photo access in weeks 1–2.

Inclusions

• The student app and the staff panel described in docs/PROPOSAL.md sections 4 and 5, with the supports in 4.2.
• Setting up the trainer's real tasks and photographs, plus up to two rounds of changes to task wording and photos. DRAFT – owner to confirm
• The deliverables: a static build zipped as stepready-prototype.zip with a README, and the live HTTPS deployment for trial.
• One hands-on training session (about 90 minutes) and a one-page staff quick guide.
• Automated tests, the requirement-to-test trace, and sign-off on a real tablet.
• Fixes to defects found against this proposal during the warranty period.

Exclusions

• Tablet hardware and mounts.
• MDM, Guided Access or screen-pinning set-up on the school's tablets.
• Cloud sync between tablets.
• Multiple student accounts.
• Staff accounts (the PIN is fixed at 1234).
• Alerts or notifications to other devices.
• Real authentication, analytics, multi-language support and video.
• Tasks beyond the three delivered, unless ordered as an optional item.

Optional items

Not included in the total above.

Terms

All terms are DRAFT – owner to confirm.

• Validity: 30 days from the date of issue.
• Payment: per the milestones above, within 30 days of invoice.
• IP and licence: the supplier keeps ownership of the source code. DSS receives a perpetual, royalty-free licence to host, use and copy the delivered build, and owns its own task content and photographs.
• Warranty: defects against this proposal are fixed at no charge for 90 days after sign-off.
• Support window: email support from the named supplier contact for 90 days after sign-off, in Singapore business hours. Ongoing support is an optional item.
• Data protection: no personal data leaves the tablet, and the supplier does not collect student data.
• GST: amounts exclude GST, which is added at the prevailing rate (9% at the date of this quotation).