One less spreadsheet.One better way to work.
Every South African business has a process people work around. Requests in a shared inbox. Job updates across spreadsheets. Start with one workflow your team can improve, using editable application source your organisation can review and keep.
- Start with a narrow experiment
- Keep source in your organisation
- Choose what to take further
A job request that reaches the right person
A regional operations team needs one view of incoming jobs, assigned owners and progress. Test the request-to-approval journey with sample data and the people who do the work.
- 01Pick one handoff and use sample data first.
- 02Let a small group try the proposed workflow.
- 03Review the evidence: stop, revise, or invest.
What to learn
Can the team complete this task with fewer unclear handoffs?
Put it to work
Start where a better workflow would help today.
Try an approval queue, a job tracker or a focused integration. Use the included app structure and components, then add your business rules and organisational controls.
A workflow proof of concept
Try a new intake, review, or approval journey before changing an established process or buying a larger system.
- Foundation included
- A prototype app, shared form and layout components, and a connected backend option.
- You build
- The workflow, test data, success criteria, and permissions needed for any live pilot.
An integration experiment
Find out whether an approved API can support a proposed tool. Make the result visible through a small working interface.
- Foundation included
- TypeScript application structure, Convex actions, and UI components.
- You build
- The API adapter, credential handling, failure paths, and a test of the technical limits.
A focused team tool
Explore a small project tracker, review queue, or departmental dashboard when existing tools leave a specific gap.
- Foundation included
- Authenticated app structure, backend models, and release workflow examples.
- You build
- The domain model, organisational access rules, data connections, and operating controls.
A practical starting point
Commit to a question before committing to a system
A smaller first step can make the investment decision clearer. It does not remove procurement, security review, or the cost of running a successful project.
- 01
Set a boundary
Name an owner, the assumption to test, a timebox, and the evidence needed for a decision. Check whether an existing tool or a non-software test would answer the question first.
- 02
Build only the experiment
Use the lightweight app and sample data where possible. Add approved services only when the experiment needs them. Commit and review changes in the organisation's repository.
- 03
Make a deliberate next decision
Stop, revise, or fund the next stage. Before a live rollout, review architecture, identity, permissions, data protection, operating costs, and long-term ownership.
Source in your hands
A common starting point, not another opaque platform
Keep the source available to the organisation, even when a pilot ends or contributors change. Use the repository to preserve the work and the decisions behind it.
The repository includes an MIT license. Keep its copyright and license notice, along with applicable dependency notices.
Version the work deliberately
The repository can hold application code, tests, configuration templates, and deployment workflows. GitHub records committed changes; Caylem does not automatically commit or enforce reviews.
Use the services your organisation approves
The connected app uses Clerk, Convex, Polar, and Resend, with deployment workflows for Cloudflare. Review these dependencies. Replacing one is engineering work, not a configuration-only guarantee.
Keep operational ownership visible
Secrets and service data do not belong in Git. Define where they live, who can access them, and how the team will export data, recover, or retire the experiment.
A good fit if…
- A small technical team has a specific workflow or feasibility question to test.
- React, TypeScript, and the relevant external services fit the organisation's constraints.
- The team wants editable source and a clear stop, revise, or proceed decision.
What to plan for
- Enterprise SSO, organisation roles, tenant isolation, audit trails, and compliance are not turnkey features of this starter.
- Use sample or non-sensitive data until the relevant services and controls are approved.
- Set an experiment budget and an owner for service costs and cleanup. Low commitment is a project choice, not a guaranteed price or outcome.
FAQ
Before you start
Practical answers for your first project.
Put a working option in front of your team.
Choose one process, one owner and one useful pilot. Review the source and stack together, then build enough to decide what comes next.
You receive the selected release of this Caylem web application as source, priced in rand. The ideas on this page are examples to build yourself. Hosting, service usage and future releases are separate.