All of design.computer runs on Cloudflare: application logic on Workers, object storage in R2, the database in D1 and custom domains provisioned on demand.
Edge infrastructure is not the right choice for every product. This page covers where it genuinely pays off and which constraints you will have to live with if you decide to build there.
Code running as close as possible to the user is both faster and cheaper than keeping a server up for short, self-contained jobs. On design.computer, every published project is served from its own address, and those addresses are provisioned on demand. In a conventional server architecture each new domain creates operational work. At the edge that step runs programmatically, which is what makes the product model workable in the first place.
Workers have limited execution time and cannot hold long-lived connections open. They are not suitable for heavy report generation, video processing or long-running socket connections. Some libraries written for the Node runtime will not run directly either. These constraints shape the architecture from day one, and discovering them halfway through a project is expensive, because by then the code has been written on the assumption that they were not there.
D1 is fine for read-heavy data at moderate scale. If you have heavy write traffic or need complex analytical queries, a managed PostgreSQL is the better answer. R2 has no egress fee, which makes cost predictable for image and file delivery. We make the choice based on the read and write balance of the product, not because a particular service happens to be fashionable at the moment.
Collecting logs from code running at the edge and reproducing a fault there is not the same as doing it on a single server. There can be small differences between the local development environment and production behaviour. That is why we set up logging and monitoring on the first day, rather than trying to build observability while an incident is already in progress and nobody can see what happened.
A finished product across web, mobile or browser extension, with the admin and integrations behind it.
Starting points, not quotes. What a project actually costs depends on scope, and we agree that in writing after discovery.
Not always. They are very good for short-lived requests and distributed read load, and unsuitable for long-running jobs. In most products, using both together turns out to be the most balanced solution.
It depends on the libraries you use. We run a compatibility review first and share in writing what can move, what has to stay on a server, and what would need rewriting before it could move at all.
It generally scales with request count, and there is no cost for a server sitting idle. On products with heavy file delivery, R2 not charging egress makes a noticeable difference to the monthly bill.
Yes. At design.computer, custom domains are provisioned programmatically through Cloudflare, so no manual step is left on the user's side. That automation is why the publishing flow can be a single click.
A short note about the product, the timeline and who it is for is enough to start. You will hear back from the engineer who would do the work, not a sales team.
Ankara / Türkiye · Working across European and US time zones
