SAS Founder Alignment Workspace v1.0
This workspace helps the two SAS founders see the full relationship between Hands, WorkPulse, operations, vendors, enterprise clients, finance and future platform capabilities before committing scarce engineering capacity.
01
Do both founders understand the overall situation and the decisions requiring alignment?
Improve founder alignment and decision quality. This is not a final strategy, PRD, architecture specification or product handbook.
Progressive Evolution: launch Hands without waiting for a full WorkPulse rebuild, while selectively reusing, wrapping, evolving and replacing capabilities based on business value.
Use this workbook to capture agreement, alternative views, open questions, capability comments and final decisions.
Download Excel WorkbookLaunch Hands without waiting for a full WorkPulse rebuild, while selectively reusing, wrapping, evolving and replacing capabilities based on business value. This is a proposal requiring founder review, not a locked decision.
03
Do the founders agree on the future shape of SAS and the role of each product or experience?
Present the ecosystem as a business model rather than a technical architecture.
Use the neutral term SAS Operational Platform. It is currently implemented largely through WorkPulse, but may evolve, be progressively modernised, or partially rebuilt over time.
04
Which capabilities does SAS already possess, how well do they serve the business, and how should they evolve?
Assess operational stability, business fit and future fit rather than calling capabilities mature just because they currently work.
Stable does not always mean future-fit. Some capabilities should be kept, some wrapped, some transformed, some replaced, and some built new.
Hands has no launched consumer identity layer yet.
Profiles and saved customer preferences are not yet a consumer workflow.
WorkPulse already knows properties for operations, but not as a consumer self-service experience.
Hands needs a public booking flow; WorkPulse can receive resulting requests.
Internal job statuses exist but need translation for customers.
Review capture is not a core WorkPulse capability today.
Membership is a future retention idea, not required to complete first jobs.
No current consumer loyalty loop exists.
The current lifecycle is proven, but SAS has adapted around its limitations.
Quotes exist for enterprise workflows and approvals.
Jobs and visits are stable operating records for field work.
Visits support scheduling and field execution.
Scheduling works for current operations but may need marketplace logic later.
Assignment exists for staff or teams, but marketplace assignment may differ.
Completion evidence exists in current workflows.
Handled operationally, but not as a future-fit marketplace workflow.
Legacy mobile application is not actively maintained and may no longer be buildable.
A future-fit vendor experience is not available today.
Vendor records exist operationally, but marketplace identity needs clearer ownership.
Compliance may exist operationally but is not a scalable marketplace workflow.
Future vendor acceptance flow is incomplete.
Vendor status capture is at risk if dependent on legacy mobile paths.
Not available in a future-fit vendor experience.
Support likely exists through operations, not a dedicated vendor workflow.
Products and services exist, but consumer packaging needs definition.
Current quote/pricing behavior may not support consumer fixed-price expectations.
Consumer checkout does not exist as a Hands flow.
Payment records exist, but consumer payment experience needs work.
Promotions are not essential for first transaction validation.
Not available as a reliable marketplace capability.
Not available as a scalable shared capability.
A marketplace-grade financial ledger is not available.
Notifications exist, but customer-safe messaging needs refinement.
Photos and evidence are part of service flows, but future use needs consistency.
Authentication exists for current users, not necessarily for consumers and vendors.
Company-scoped access exists for current operations.
Operational reporting exists, but launch learning metrics need definition.
Enterprise capabilities exist and need protection during Hands launch.
Clean integration boundaries around legacy capabilities need validation.
05
Which overall direction should SAS take?
Present four genuine options fairly, including the risks and conditions attached to each.
Progressive Evolution is the current recommendation, not an agreed decision.
Makes sense when launch speed is more important than platform cleanliness and pilot volume is controlled.
Makes sense if current WorkPulse cannot safely support any consumer launch.
Works when founders agree to prioritise the minimum viable business and invest in strategic capabilities in sequence.
Only reasonable if the tool is a replaceable execution interface, WorkPulse remains authoritative, evidence and statuses sync, payouts stay under SAS control, and an exit plan exists.
06
Where should SAS invest its limited engineering resources first?
Organise investment around business outcomes rather than product names.
Highest priority: Hands customer launch experience, minimum integration with existing WorkPulse, and reliable end-to-end job completion. High priority next: modern vendor execution experience, integration boundary, and request workflow evolution.
Hands customer experience, Service discovery, Booking, Customer account or lightweight identity, Customer communication, Status tracking, Basic checkout
Request evolution, Operations workflows, Scheduling and assignment, Vendor coordination, Proof of completion, Exception management
Vendor onboarding, Job acceptance, Status updates, Onsite additions, Proof of delivery, Completed job history, Vendor support
Vendor entitlement, Settlement, Payout, Ledger, Refunds, Deductions, Partner commissions
Promotions, Referrals, Guarantee, Membership, Loyalty, Reviews
Production support, Critical fixes, Existing client workflows, Security, Infrastructure maintenance
Highest priority is the customer launch experience, minimum WorkPulse integration and reliable job completion. High priority is vendor execution and workflow evolution. Marketplace finance follows. Membership, loyalty, AI, advanced bidding and regional expansion come later.
07
What is the Minimum Viable Business required to launch Hands?
Customers do not buy software. They buy a completed service. The launch must cover customer acquisition, booking, operations, vendor fulfilment, completion, payment, vendor compensation, learning and feedback.
Decide whether the target is a controlled pilot or an operational MVP before finalising engineering scope.
08
How should SAS sequence the identified investments?
Keep the roadmap simple and business-led. No fixed dates are invented.
Sequence vendor enablement and marketplace finance before membership and broad growth features.
09
What have the founders agreed, and what still requires discussion?
Record decision topics, options, current recommendations, reasoning, risks and next actions.
Use this workbook to capture agreement, alternative views, open questions, capability comments and final decisions.
Download Excel Workbook10
What supporting material should founders reference without treating it as an agreed strategy?
Move supporting material here so main chapters stay decision-focused.
Includes the marketplace vision, RFQ and direct-booking models, aircon-first launch, condo programme, retail partner model, membership, Hands Guarantee, leakage control, vendor model, fixed pricing and future bidding, vendor wallet, settlement and payout concepts.
Open referenceWorkPulse already supports many operating capabilities: requests, quotes, jobs, visits, clients, properties, scheduling, staff, service reports, invoices, payments, notifications, GPS and permissions.
The admin panel supports operational coordination but reflects legacy React-era workflows. Several current processes work because SAS adapted around the software, not necessarily because the product perfectly fits the future model.
The ecosystem includes a legacy Node.js and FeathersJS backend, PostgreSQL and Sequelize, Redis and Bull queues, React 16 admin panel, enterprise portal capabilities and a vendor mobile application risk.
Hands is similar in category to ServisHero, but SAS has an existing operational base, field-service experience and enterprise relationships. The discussion should focus on what SAS can do credibly with its current resources.
11
Do both founders share the same meaning for important terms?
Keep language business-friendly and reduce avoidable misunderstanding.
The proposed consumer-facing SAS brand and product for customer acquisition, booking, support and future retention.
The current proprietary field-service platform that powers much of SAS operations.
The neutral name for the shared operational foundation, currently implemented largely through WorkPulse but able to evolve over time.
A business function SAS needs, independent of the specific software that implements it.
How reliably a capability works in current operations.
How well a capability supports today’s business needs.
How well a capability supports the future Hands, marketplace and platform direction.
Launching Hands while selectively reusing, wrapping, enhancing, replacing and building capabilities.
The operating model that coordinates customer demand, vendor supply, service execution and exceptions.
The work required to assign, perform, complete and verify a service.
The onboarding, job execution, status, proof, support and earnings flow for vendors.
The pricing, checkout, promotions, margin and payment behavior around a service transaction.
The calculation of what a vendor should earn for a completed job.
The process of allocating revenue and obligations after a job is completed.
The movement or recording of money owed to vendors.
An auditable record of financial events, adjustments and balances.
The service promise that gives customers confidence in the outcome.
A future retention model with benefits, savings, priority or bundled value.
The authoritative place where a business fact is stored and trusted.
A workflow intentionally handled by people during early validation instead of automated immediately.
A limited launch using trusted vendors and manual operations to validate the business loop.
A launch standard with enough platform support to run more reliably beyond a small pilot.
A temporary third-party tool used only as a replaceable execution interface.
Expose a cleaner boundary around legacy behavior without directly rebuilding it first.
Change a capability’s business rules or workflow because the business has outgrown the current shape.
Retire a capability and build or adopt a future-fit alternative.