Chalice Network is built around one simple belief: small businesses and the professionals serving them should spend less time on operational noise and more time on real work that creates outcomes. Inside their ecosystem sits a large community of service providers, including financial advisors who run retainer-style practices, manage recurring client relationships, and deal with the same invisible friction month after month. Billing. Follow ups. Payment status confusion. Manual invoices. Awkward conversations. Not hard problems individually, but together they quietly eat time, attention, and trust. Chalice wanted to remove that friction by launching ChalicePay, a billing and payments product that fits the advisor workflow and makes getting paid feel predictable, transparent, and professional.
When we started, the goal was not to “build a billing tool.” The goal was to build the first real version of a product that advisors would actually use without being trained, and that clients would accept without hesitation. ChalicePay needed to support subscriptions and one time invoices, let advisors request payments confidently, and give clients a straightforward way to pay and manage their commitment. It also had to respect a simple reality: in financial services, payment flows are not a casual feature. They sit next to trust, data security, and compliance expectations, even when you are building an early version. That meant we had to move fast, but not recklessly.
The first step was clarity, not code
Before building anything, we ran discovery in a way that forced the product to become real on paper first. Not vague requirements, not wish lists, not a collection of feature ideas. We needed to understand what a successful “first release” meant for Chalice, what workflows mattered most, where the hidden risks were, and what decisions would save months later. Our Head of Software Delivery and Business Analyst worked directly with Chalice’s CTO to elicit requirements, explore solution options, and document the execution plan in a Project Charter. That charter became the shared source of truth, and it solved a problem that kills many early builds: everyone thinks they agree until the sprint starts.
Once the direction was locked, we moved into design and specification with disciplined weekly checkpoints. Because ChalicePay was being built from scratch, we treated UI and UX as part of the product foundation, not as a nice-to-have layer on top of engineering. While the design was being produced, we worked in parallel on a Software Requirements Specification that translated the product vision into clear scope, roles, flows, and acceptance criteria. The team synced frequently to keep requirements and screens aligned, and we held weekly sessions with Chalice stakeholders to review progress and confirm decisions. By the time we reached the final approval demo, the product was no longer an abstract plan. It was defined well enough to build without constant rewrites, and that is what made development move quickly later.
Building the MVP around what actually matters: subscriptions, invoices, and trust
For the first release, Chalice wanted to launch the core advisor-to-client billing flow with minimal complexity and maximum reliability. We built the MVP on top of Stripe as the payment processor, because the fastest way to ship a trustworthy payments product is to leverage an infrastructure that is proven and widely accepted. The system enabled advisors to create subscription payment requests and issue one time invoices, while clients could pay through a cleaner, more confident flow. Subscriptions were designed to be trackable and cancellable by both parties, because long-term retention depends on transparency. A billing product that makes clients feel trapped is not a product, it is a churn machine.
Execution was structured and sprint-based. We onboarded a dedicated team with backend and frontend engineers, QA, and delivery leadership, and we ran development through two-week sprints with user stories and Scrum rituals that kept the work measurable and steady. The implementation used a monolithic approach to optimize speed to rollout and maintain coherence in the early stage, with a Python backend and React frontend. The product scope focused on two key user roles: the advisor as the account owner and the client as the payer, with Stripe integration at the center.
Payments work has a unique kind of complexity. The challenge is rarely the API itself. The challenge is translating a payments provider’s primitives into your product’s business logic in a way that remains consistent, testable, and understandable. Stripe is powerful, yet it has its own rules, behaviors, and edge cases that only show up when you build real workflows around it. Our engineers had to go deep into Stripe APIs and connect them with ChalicePay’s domain logic, while the delivery process kept those discoveries from turning into scope chaos. That is where the structure paid off. Instead of improvising, we captured what we learned, aligned on decisions quickly, and kept shipping.
Expanding capability without breaking the foundation
After the MVP scope was delivered, Chalice was in a strong position to extend the product in a way that actually increased value rather than adding noise. We moved into advanced functionality that supported how advisor organizations operate in real life. This included additional advisor roles such as managing advisor and standard advisor, features around advisor management, and enabling free use for existing Chalice clients. We also added more automation and stability to the payment lifecycle through webhooks, which reduced manual involvement and improved reliability of payment status tracking across the system.
Security and data handling were treated as product decisions, not just technical checkboxes. Sensitive payment and identity data was tokenized and submitted securely to Stripe. Test and production environments were separated properly. Sensitive data stayed within Stripe and could not be retrieved from ChalicePay, which reduced exposure and aligned the product with trust expectations from the start. QA included regression and unit testing, and the team navigated the practical challenge that Stripe API behavior can introduce into manual testing workflows, keeping the delivery on track through planning and tight collaboration.
Outcome
ChalicePay reached beta testing as a working billing system built for real advisor workflows, with subscription and invoicing capabilities, Stripe-based payments, role-aware functionality, and event-driven payment tracking. More importantly, Chalice ended up with a foundation they could evolve with confidence. The product was not a prototype for a pitch deck. It was an operational MVP that could be placed in front of real users, tested, improved, and scaled based on evidence.
