What a design partner gets, and why it is a subscription rather than a project

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, and the relationship is a subscription with a minimum term of twelve months.

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 subscription 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 order of databases is set (SQL Server now, MongoDB next, Postgres after that), 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 and not a project

A project 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 price covers the running, not the building. Support, monitoring, tuning, product improvements and deployment 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 across the same term for a little more.

Why twelve months at minimum

The minimum term is twelve months because that is roughly how long it takes to see the whole picture. A quarter may be enough to deploy and see the first effect on the bill. It is not enough to live through a peak season, a schema change, a cloud provider incident and a couple of releases that touch the busiest tables.

A shorter term would also push both sides toward the wrong behaviour. We would optimise for a quick demonstration rather than for durable operation, and the partner would judge the relationship before it had done its job. Twelve months aligns the incentives: we are paid to keep it working, and the partner has time to see that it does.

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; SQL Server is available now, with the others following in that order. 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.