Shuru Technologies Pte Ltd
Implementation and delivery plan
Nine work packages, three engineers running in parallel, twenty-two weeks from kickoff to handover. Below is what gets built, in what order, by whom, and what it costs.
Each wave runs three packages at once. A wave closes when its last package is accepted, and the engineers move straight onto the next three.
Worksparks already earns revenue from individual managers holding open-ended reflective conversations. The next move is selling to employers: companies, government departments and professional bodies that want a cohort of managers through a structured 90-day programme, and want to see what changed afterwards.
That shift needs four things the product does not have yet.
Verified data handling, versioned consent, and a hardened platform that a corporate security questionnaire cannot pick apart.
Organisations, seats, admins and programmes, with a programme a non-developer at Worksparks can author without asking an engineer.
Counted practice and completed commitments, recorded in a structure that holds no conversational text. Satisfaction scores prove nothing to a buyer.
Activation and month-three retention measured against a benchmark, with cost per active user attached to the same view.
One constraint sits above all four. Worksparks is private by architecture, not by policy. An employer gets aggregate evidence they can defend to their own board. No employer, admin or reviewer ever reads an individual’s coaching transcript.
Surveys and peer recognition stay out of scope for the same reason. Both quietly break that promise, and both distort what a manager is willing to write.
Three full-stack engineers work at the same time, one package each. When a package is accepted, that engineer picks up the next one in their column. A Head of Engineering holds architecture and correctness across all three streams. One QA engineer tests each package as it lands, then runs the release cycle at the end. Design is called in when a package needs screens, and not otherwise.
WS0, then WS3, then WS6, then the PWA and push component of WS8. Release testing at the end.
Runs the weekly review with you, tracks dependencies you own, and keeps acceptance moving so a wave does not stall.
Three engineers, always running at once. Wave 1 is WS0, WS1 and WS2. Wave 2 is WS3, WS4 and WS5. Wave 3 is WS6, WS7 and WS8. Each engineer starts the next package as soon as the current one is accepted. Four weeks of release testing close the engagement.
Effort below is one engineer working on that package. Running three engineers in parallel shortens the calendar, not the effort.
| Package | Wave | Effort | What it covers, and what we need from you |
|---|---|---|---|
| WS0Security hardening | Wave 1 | 3 weeks | Secrets moved into managed storage, access rules enforced server-side, and a build pipeline running from day one. Cloud and repository owner access is needed on the first morning. |
| WS1AI safety, boundaries and escalation | Wave 1 | 4 weeks | Crisis routing, coaching boundary checks, and a safety suite of more than a hundred adversarial prompts wired into the pipeline. Worksparks supplies the escalation copy during this wave. |
| WS2Consent, memory control and data rights | Wave 1 | 3 weeks | Versioned consent, data export, deletion that reaches derived records, and a memory view a manager can inspect and correct. Design is pulled in for the memory screens. |
| WS3Coaching core | Wave 2 | 5 weeks | Adaptive prompting, reflection and pattern views, and a framework library a non-developer can edit without a deploy. Framework text comes from Worksparks. The retrieval approach is settled inside this wave. |
| WS4Courageous Conversations | Wave 2 | 3 weeks | Guided preparation that separates what was observed from what was inferred, then writes the follow-up. The shortest package in the wave, which frees two engineer-weeks we would rather spend than leave idle. |
| WS5Behaviour-change engine | Wave 2 | 5 weeks | One-off commitments split from cue-based practices, with a consistency view a manager can recover after a bad fortnight. No streak punishment and no gamification. |
| WS6Accounts, cohorts and programme delivery | Wave 3 | 4 weeks | Organisations, admin against member, seat invites, cohorts, and one authorable programme. Worksparks confirms the seat rules, including what happens when someone leaves, before this wave starts. |
| WS7Measurement and evidence | Wave 3 | 5 weeks | The BehaviouralAction record and employer reports that stay blank below a group of ten. Individual coaching text never reaches an employer view, on any filter combination. |
| WS8Instrumentation, PWA and voice | Wave 3 | 10 weeks | Three components priced apart: retention and cost tracking at 4 weeks, an installable app with push at 4 weeks, and voice transcription at 2 weeks. Two engineers join this package once WS6 and WS7 are accepted. |
| TotalAll nine packages | 3 waves | 42 weeks | Package effort stays at 42 engineer-weeks whoever builds it. The calendar is 22 weeks because three people work at once and four weeks of release testing sit at the end. |
Each row is one person. Solid blocks are package work. Dashed blocks are weeks where a short package leaves an engineer free inside their wave, and section 08 proposes what to do with them.
The privacy promise is the product. Most of what follows exists so that promise holds under a procurement review, not because it reads well in a proposal.
Pricing is a monthly team rate, not a per-package quote. You retain the same people for the whole engagement, so the shape of the bill stays flat and predictable rather than spiking with whichever package happens to be running.
| Scope group | Timeline | Packages | What lands | Cost |
|---|---|---|---|---|
| Wave 1Trust and safety | Weeks 1–4 | WS0 WS1 WS2 | A hardened platform, crisis routing with a safety suite in the pipeline, and consent, export and deletion a buyer can audit. | $12,100 |
| Wave 2Coaching and behaviour change | Weeks 5–9 | WS3 WS4 WS5 | The structured coaching session on an editable framework library, guided conversation preparation, and the commitment and practice model. | $15,200 |
| Wave 3Enterprise delivery and evidence | Weeks 10–18 | WS6 WS7 WS8 | Organisations, seats and cohorts, the suppressed employer report, retention and cost tracking, the installable app with push, and voice. | $27,200 |
| ReleaseTesting, fixes, production launch and handover | Weeks 19–22 | All | Integration testing across the nine packages, fixes, schema documentation, the sub-processor register and the incident response plan. | $12,000 |
| Full delivery | 22 weeks | WS0–WS8 | Roughly five and a half months, at about $13,000 a month for the build. | $66,500 |
Your scope marks the first two as “where feasible”, so we have costed them rather than guessed at them. Tick anything you want in and the total updates.
Third-party costs are invoiced to Worksparks directly: the security reviewer, the clinical reviewer, any assessment instrument licence, and all running model, transcription, hosting and push notification costs. Support during the design-partner cohorts is a separate monthly line. Australian data residency is a separate project with its own data move if done later, and is quoted once the question in section 09 is answered.
Every number above rests on these. If one of them is wrong, tell us early and we will reprice that part rather than absorb it quietly and argue about it in month six.
Effort is per engineer. Each package size is one engineer working on that package. Three engineers in parallel shorten the calendar, not the effort.
Access on day one. Cloud and repository owner access is available the first morning. WS0 cannot start without it, and a week of delay there moves every wave behind it.
The codebase is extended, not rebuilt, with two exceptions we want on the record: the framework content and retrieval layer in WS3, and the organisation model in WS6. Both are new construction rather than completion.
No residency migration is priced. The platform stays in its current region. If Australian residency is required later, that is a separate project and a data move.
Third-party fees sit outside. Security reviewer, clinical reviewer, instrument licence, and all running model, transcription, hosting and push costs are invoiced to you.
Worksparks supplies content on time. Framework text, escalation copy and confirmed seat rules arrive before the wave that needs them.
Acceptance inside five working days. A wave cannot start until the previous one is accepted, so a slower turnaround moves the end date rather than compressing the work.
Shuru builds interface design with AI for new screens. If your brand designer supplies page comps instead, we can utilise that or if you add the design line we can build customised interface designs.
Cohort support is separate. Running support while your design partners are in the field is a monthly retainer, not part of the build price.
Some work runs on other people’s calendars. The security review, clinical sign-off on the safety taxonomy, push testing on real handsets, and the backup restore drill all take the time they take. Adding engineers does not shorten any of them, which is why Wave 3 is nine weeks rather than seven.
One shared build, not one per client. Enterprise features are configured per organisation rather than forked per customer. A design partner asking for a bespoke variant is a change request.
Five changes we would make to the plan as written. None of them add cost. Four use capacity you are already paying for, and the rest are about deciding things early enough that they stay cheap.
WS2 has to show a manager what the system remembers about them. What gets stored depends on which retrieval approach wins, and that benchmark currently sits in Wave 2. Running it a wave earlier means the memory view describes something real instead of a placeholder that gets rebuilt two months later.
WS6’s participation tracking has to respect the group-of-ten threshold, and WS7 owns the suppression logic that enforces it. Two engineers building in parallel against an unwritten contract will produce two versions of it, and the one bolted onto a single report is the one that has to be ripped out later.
The BehaviouralAction record has the same problem. It is the structure the entire privacy claim rests on, and it should exist before anything writes to it.
Five pieces get duplicated if each package builds its own: the content editor shared by WS3 frameworks and WS6 programmes, the evaluation harness that WS1, WS3, WS4 and WS5 all need a suite on, the suppression service shared by WS6 and WS7, the audit trail covering admin actions and reviewer access, and the cost measurement WS3 reports and WS8 captures.
None of these is expensive on its own. Built separately they become five pairs of nearly identical code with no single place to answer who saw what.
The security reviewer, the clinical reviewer for the safety taxonomy, and the legal advice behind the escalation policy all run on someone else’s availability. A reviewer booked out for three weeks is three weeks off the end date, and no amount of engineering capacity changes that.
Booking them during kickoff is what keeps them off the critical path. The escalation advice in particular blocks WS1, which is the package you called most urgent.
The platform runs in a US region today. The database location is fixed when a project is created, so moving later means a new project and a full data migration rather than a settings change. Every month of data makes that move more expensive.
If Australian residency is coming within the year, deciding it now costs a conversation. Deciding it in month eight costs a separate project on top of a live customer base.
Nine open questions. Where we have a view, it is written underneath so you can accept it and move on rather than start from a blank page.
This changes WS0, and the answer gets more expensive to act on every month the platform holds more data.
The scope requires an independent review but does not settle the commercial side of it.
Our suggestion: you appoint from a shortlist we give you, tested against OWASP ASVS Level 2 plus cloud configuration, with fixes and one retest inside our price and the reviewer invoicing you directly.WS1 cannot close without it. We need the date at kickoff rather than the answer, so we can sequence around it.
Australia only, or your design partners’ countries too? Each region adds research now and a standing commitment to keep those numbers current afterwards.
Both are written as “where feasible” in the scope. We have priced them as options in section 06 rather than guess, but a maybe cannot be built.
It is faster to build and better for non-developer editing, and it adds a sub-processor to your register.
Our suggestion: hosted, with the vendor named in the proposal so your privacy documentation is accurate from day one rather than amended later.WS6 cannot be built without a rule here. It also exposes something worth fixing in the same package: organisation ownership is currently derived from the founding user, so there is no way to transfer it or add a second owner.
We have priced the first. If you need bespoke designs, then the design line goes in.
Three RFCs sit on the critical path: retrieval schema, tenancy model and suppression filter. A week of turnaround is workable. Three weeks is not.
Worksparks has the harder half already: a product people are ready to pay for and a position that holds up under scrutiny. What it needs now is the engineering to sell it to an employer without either party giving up the privacy promise.
Three engineers in parallel across WS0 to WS8, four weeks of release testing, twenty-two weeks end to end. Shared architecture, shared QA and on-demand design keep the work correct without adding seats you would be paying for either way.