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.
In design.computer's published scope, Workers handle publishing and routing, R2 stores pages and D1 records projects. Custom domains are provisioned through Cloudflare. For another product, compare the workload, storage needs and operating responsibilities with the current server setup before choosing an edge architecture; this example does not establish a speed or cost saving for your application.
A migration scope should list runtime dependencies, request duration, background jobs, connection requirements and the data each operation touches. Check those requirements against the intended deployment and test a representative workflow before moving it. Agree what can move, what needs a separate service and what must stay on the current backend, with rollback and operational ownership defined in the release plan.
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.
Start with the task you need to improve. These pages connect a published delivery example to discovery questions for a new engagement.
For Mankato research-product teams publishing reviewed interactive demos with explicit prototype revisions, approved input references and public release context.
Explore the scope and discovery questions →For Provo hackathon organizers connecting team-owned demo projects, a selected judging edition and deliberate public gallery publication.
Explore the scope and discovery questions →For Worcester coding-workshop teams connecting learner project drafts, instructor review and an approved public demo gallery.
Explore the scope and discovery questions →For Santa Rosa agencies developing prototype publishing tools that keep project identity, preview revisions and client-review destinations understandable.
Explore the scope and discovery questions →For Louisville AI-tool teams giving published prototypes an owned project dashboard, clear URLs and domain-connection states.
Explore the scope and discovery questions →For Austin developer-tool teams connecting AI-generated code, a browser capture workflow, hosted pages and an account dashboard.
Explore the scope and discovery questions →Senior engineers building your product with AI coding agents: web, mobile, SaaS or browser extension, reviewed before anything ships.
AI-accelerated development, billed monthly. We confirm scope, capacity and start date in writing before checkout.
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.
Share the repository, runtime dependencies, representative request timings, background jobs and storage requirements. Describe the deployment process and who responds to incidents. The assessment should identify a bounded workflow to validate, its acceptance checks and a rollback path before a wider migration is agreed.
One paragraph on what you are building, roughly when you need it, and who it is for. No brief, no form with fifteen fields.
From the engineer who would do the work, not a sales team. If we are not the right fit we say so, and where possible we point you somewhere better.
Scope, price and timeline in writing before anything is committed. You decide with the numbers in front of you.
No long contract to begin, no lock-in to our tooling, and the code is yours from the first commit.
Start a conversationA 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
