What a design partner gets, and why a subscription follows the contract

Most software companies sell one of two things: a licence you install and forget, or a project with a start date, an end date and a handover. redfly sells neither. Today the way to adopt redfly is to become a design partner. It starts with a design-partner contract, followed by an annual or monthly subscription, because keeping sync running is a full-time job.

What the relationship includes

The first thing a design partner gets is an architecture review against their own schema (the layout of tables and fields in their database). We look at the shape of the data, the read and write patterns and the peaks the business has to survive, and we say where redfly helps, where it does not, and how large the footprint (the servers and memory it needs) has to be. This happens before anything is deployed, and it is part of the design-partner contract rather than a separate engagement.

The second is the software itself: the redfly API (the single entry point an application calls for its data) and the Sync Service that keeps the memory cache in step with the database. It runs in the partner's own cloud account by preference, as a fully managed service in redfly's cloud, or on the partner's own servers. Whichever shape suits, the partner's application code contains no cache logic to write or maintain.

The third is our team's direct involvement. We set redfly up with the partner, against their database, and we stay until the numbers show up on their bill. Monitoring, tuning, schema changes and upgrades are included, with direct access to the engineers who built the product.

Influence over what gets built next

Design partners shape the product. redfly is early, and the order in which things get built is decided by what the partners in front of us need rather than by a list drawn up in advance. The databases are set (SQL Server, MongoDB and Postgres), but what gets built around them is shaped by the partners using it.

Once the programme closes, the product will reflect the priorities of the partners who were there. We are looking for a small number of companies whose problems are representative of the market we serve, and we would rather solve their problems thoroughly than solve everyone's problems partially.

A design partner is not a customer who arrived early; it is a company that helps decide what the product becomes.

Why a subscription after the contract

The contract covers the architecture review and the first deployment, and like any project, it ends. Keeping a memory cache truthful against a live database does not. Schemas drift as features ship, traffic moves around as the business grows, and a table that was quiet in March is busy in November. If redfly were sold as a one-off build, the day after handover would be the day the partner started re-learning everything we know about running it.

So the subscription covers the running, not the building. Support, monitoring, tuning and product improvements are included for as long as the subscription lasts. It is not priced per seat or per request. Payment is annual at the lower rate, or monthly for a little more.

No free trial, no free review

There is no free trial, and there is no free review either. We say this plainly because it is unusual, and because the reasons are practical rather than commercial. An architecture review against a real schema is engineering work by senior people, and much of the value early in the relationship comes from it. Giving it away would mean doing it less carefully.

What we offer instead is proof of a different kind. Live consumer products run on redfly today, in production, on a small infrastructure footprint, and anyone can open them and see how they behave. The source code for the client side is public. And the architecture review comes before anything is deployed, so a partner knows what the footprint and the expected savings look like before the system touches their traffic.

What we ask of a partner

The requests are modest. We ask for a real database with real traffic, on SQL Server, MongoDB or Postgres. We ask for one technical contact who can grant access and make decisions. We ask for candour about what is working and what is not, because a partner who is quietly unhappy teaches us nothing.

We also ask for patience with an early product. Some rough edges exist, and design partners see them first. In return, design-partner pricing is an early-customer rate held for the length of the contract, and the programme does not stay open indefinitely.

redfly fits companies whose database has become the most expensive and fragile part of their stack, and who would rather work closely with the team that built the fix than buy a box and hope.