Opinionated defaults, not locked-in choices

CFE needs a clear reference stack. When I share a workflow, I want people to see what I actually use, understand how the pieces fit together, and have a concrete path to reproduce it.

Slack and Stripe are tools I’ve used for years. As a web developer, I want CFE’s reference stack to come from that experience, so I can explain the choices and their limits.

Slack as the messaging reference

For messaging, I’m starting with Slack. KJL already handles most of its work communication there. This isn’t a platform picked just for a demo. It’s where the work happens, which makes it easier to notice awkward handoffs, missing context and things that need fixing.

That doesn’t mean everyone has to use Slack. You might prefer Discord or another platform. If it supplies the capabilities a workflow needs, it should be possible to build a compatible integration.

But compatibility needs to mean something. Can we identify the conversation, route a reply to the right place, respect permissions, and recover when something fails? Those requirements matter more than matching a brand name.

I’d rather document one tested path well than pretend every possible stack works the same. Slack will be my messaging reference. Other implementations can adapt the same workflow, with their differences and limitations made clear. That’s a direction for compatibility, not a claim that Discord support already exists.

Stripe as the payment reference

I’m taking the same approach with payments. Stripe is the reference because I know it from years of using it in my work.

The goal is for Codex to help people build a shop or sell a service using their own Stripe setup. For a business accepting payment for its own products or services, that can start with a normal Stripe payments integration, such as Stripe Checkout. That alone doesn’t require Connect.

Stripe Connect is for the platform side: onboarding sellers or service providers, working with their connected accounts, and routing payments and payouts between the parties. I want CFE examples to make that distinction clear, so people can choose the setup their business actually needs.

I plan to build CFE Payment through 1wayto as a reference implementation. The idea is to give people a concrete example they can adapt with Codex to generate a shop or service-selling site more easily. That example is still planned, not available today. 1wayto is a contributor to the independent CFE project.

Stripe will be the reference, not a requirement for every implementation. Other payment providers can be explored against the same workflow needs, with their differences made explicit.

Offer what I know

AI is increasingly doing work that used to require specialist expertise. To me, that makes it more important to be careful about what I offer.

The market is already crowded with big promises and little accountability. I want to offer something I know: tools I’ve actually used, workflows I can explain and verify, and clear limits on what they can do. I want to be accountable for the claims I make, including being clear about what still needs human review.

That’s why these choices come from my experience as a web developer. I’d rather start with a concrete, tested path than promise that every stack or every AI-generated result works the same.

Opinionated defaults give us somewhere concrete to start. Open source gives us room to change it.