Your team’s expertise.A head start on delivery.
Your South African team can deliver for clients here and abroad. Give each suitable React and TypeScript project a familiar starting structure, from discovery prototype to customer portal. Put more engineering time into the business rules, integrations and experience your client hires you for.
- Reusable across client projects
- Client-controlled source
- Setup and release workflows included
A customer portal for a service business
A client’s team chases job details across email, WhatsApp and spreadsheets. Give customers one place to submit a request and check progress. Use discovery to prove the flow before a wider rollout.
- 01Prototype one customer journey with sample data.
- 02Observe users and agree what is worth building.
- 03Implement the real workflow and document handover.
What to learn
Does the proposed workflow work for the people who will use it?
Put it to work
A useful starting point across your delivery pipeline
Reuse pages, components and the development workflow across suitable engagements. Give each client the product decisions, data model and review their project needs.
A discovery prototype
Give a proposal or discovery phase something people can use. Test a journey before estimating an entire application around it.
- Foundation included
- A lightweight Next.js prototype app and shared design components.
- You build
- The client's flow, realistic sample data, and a plan for testing the assumptions.
A client or customer portal
Create a branded place for customers to submit information, see progress, or work through a service with the client's team.
- Foundation included
- Authentication, backend structure, reusable UI, and email foundations.
- You build
- Account boundaries, roles, workflow states, integrations, and customer-specific screens.
A client’s new software revenue stream
Help a client package their industry knowledge into a software tool or digital product. Start with a storefront and purchase journey, then build the offer customers use.
- Foundation included
- Marketing blocks, a one-time purchase flow, source access patterns, and release tooling.
- You build
- The product, pricing rules, onboarding and operating model. Check seller eligibility. Polar is not the payment route for your agency’s service invoices.
A practical starting point
Scale the repeatable work. Keep the craft.
For a small studio or an established software house, the value is a starting point the team can review, learn and reuse. Your delivery standards still lead.
- 01
Agree a team starting point
Have a technical lead review the source, service choices and licence. Adopt it for suitable new projects. Capture your conventions alongside the included contributor instructions.
- 02
Build the part the client needs
Build the workflow, apply the client's design, and configure the services. Review data access, test important paths, and adapt the release workflows.
- 03
Hand over more than a ZIP
Agree who controls the repository, domains, and service accounts. Document deployment, configuration, data handling, and support so the next maintainer can operate it.
Source in your hands
Make the client handover part of the product.
Keep the application in the agreed repository from day one. Give the next maintainer the source, setup instructions and release path, with clear ownership of the services around it.
The repository includes an MIT license. Keep its copyright and license notice, along with applicable dependency notices.
Reuse is allowed by the included license
The current MIT license permits modification, commercial use, and redistribution. Preserve required notices and check dependency and service terms for each delivery.
Give each delivery a clear boundary
Independent client projects need separate repositories and appropriately separated services. The two included storefronts show reuse within one business, with a shared identity and database. They are not isolated client tenants.
Make maintenance explicit
Define who handles dependency updates, incidents, usage costs, and backups. A source handover alone does not transfer every service account or operational duty.
A good fit if…
- Your team delivers React and TypeScript web applications.
- Projects share common application needs but have distinct client workflows.
- You want clients to receive editable source and a documented release path.
What to plan for
- A prototype is evidence for a decision, not automatically production-ready software.
- Client permissions, data separation, integrations, and security requirements need project-specific work.
- Service eligibility, usage costs, hosting, and support belong in the proposal. The source purchase does not cover them.
FAQ
Before you start
Practical answers for your first project.
Give your next brief a working start.
Review the stack with your technical lead. Check the release and rand price. Make Caylem the starting point for a suitable client project, then build the work your team does best.
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.