Dardo
Start a project
ENESPT
ENESPT

Web development for the US and Latin America

Dardo builds fast, maintainable websites for teams in the US and Latin America. We turn designs into a frontend, content model, forms and integrations, then test loading, errors, keyboard focus, long content and submitted inquiries. Based in Bogotá, we collaborate remotely in English or Spanish, with meeting overlap agreed before work starts.

By Nicolas Ceron9 min read
Get a proposalMessage us on WhatsApp
Dardo / Editorial illustration
On this page

What our website development covers

Development can follow Dardo's own web design or start from designs supplied by your team or another studio. Either way, the proposal lists the templates, states and integrations being built, who supplies each input and how each part is accepted.

  • Responsive frontend implementation of every agreed template and state
  • Content model, CMS setup and publishing workflow
  • Forms and agreed integrations, tested with real submissions
  • Metadata, structured data and crawlable page structure
  • Accessibility and performance checks on representative pages
  • Launch checks, deployment and handover documentation

When web development is the right starting point

Start here when the design is approved, or close to it, and the risk is in the build: content your team has to publish, data from another system, a form that must reach the right person or performance on real phones. Bring the designs, a page inventory and a list of integrations. A marketing website, a logged-in dashboard and a transaction system have different acceptance criteria, so we define them before estimating.

If you don't have designs yet, start with custom web design, which covers both. If the brief is led by motion, WebGL or 3D, creative development is the closer fit. And if the core scope is a complex logged-in product or a long enterprise integration program, a larger application team may serve you better; we'll say so early.

The stack we build with

We choose the stack per project and explain the choice in the proposal. Our published work uses Astro and Next.js with TypeScript, deployed on Cloudflare Workers or Vercel. For content-led marketing sites, Astro is a strong fit: pages are rendered to HTML ahead of time and JavaScript ships only to the components that need it, which keeps pages light and easy for search engines to read. Next.js suits interfaces that behave more like an application.

When a site needs server logic, such as payments, accounts or data from another service, we add it where it's needed rather than turning every page into an app. Superame, a public project leaderboard built with Astro, stores its ranking in a Neon database and sends buyers to a hosted checkout; its server verifies each signed payment callback before adding credit. If your team must stay on a specific CMS or platform, put it in the brief and we'll confirm before quoting whether we're the right team for it.

A CMS your team can actually use

A content management system only helps if its fields match how your team publishes. Before building, we map each content type, who edits each field, what needs approval and which pages are fixed layouts versus reusable entries. On A medio tono, programs and teachers are maintainable entries rather than hand-built pages, and a course link opens a teacher directory already filtered to that instrument.

Dardo's own website works the same way: its pages are a static Astro build served from Cloudflare, articles are written in a separate headless CMS, and publishing an article triggers a rebuild. Static output keeps hosting simple and pages fast, and editors never touch the code.

Integrations, forms and performance

The build starts with a route inventory and an integration map: what each form or API must do, which third-party accounts you must own, and what the visitor sees when a service is slow or fails. A polished frontend can hide an undefined inquiry workflow, so before launch we send real test submissions and confirm they arrive where they should.

Performance is part of acceptance, not an afterthought. We agree on the templates and devices to test and check loading behavior and page weight before release. A medio tono runs Vercel Analytics and Speed Insights in production, and Janus Observatory's implementation includes bundle budgets and browser QA, with a release workflow that checks the build and visual regressions.

Multi-location and franchise websites

Businesses with several offices, clinics, stores or franchisees need one brand system and one content model, with a real page for each location: its address, hours, team, services, photos and the way to contact that place directly. Head office controls the shared pages and the brand; each location edits only its own details, with roles that keep the two apart. A real estate agency adds its listings to that model, each filed under the office and advisor that sell it.

Google asks for one Business Profile per location and a website page that represents that location, and recommends marking up each location separately with its own URL. We build the location pages and structured data that way. We do not clone city pages for places where you have no office, because pages that only swap a place name are treated as doorway pages.

How we test before launch

A representative page is built and tested on the agreed screen sizes before the remaining templates are completed, so problems surface while they're still cheap to fix. Acceptance covers:

  • Keyboard use and visible focus
  • Long, short and missing content without broken layouts
  • Loading, empty and error states, and reduced motion where there's animation
  • Form delivery to the real destination, with a confirmation message
  • Canonical URLs, redirects, metadata and structured data
  • Analytics events, consent behavior and production integrations

Who owns the code, and what you get at handover

Handover names the repository, hosting, domains, CMS, credentials, documentation and maintenance owner, so the website stays operable after release. We prefer client-controlled hosting and accounts wherever the platform allows it, and the proposal states ownership of code, design assets and any licensed dependencies before work begins.

A nearshore team for the US and Latin America

Dardo is a team of three based in Bogotá and led by founder Nicolás Cerón, so you talk directly with the people writing your code. Bogotá is on UTC−5 all year, with working-day overlap for US and Latin American teams. We agree on calls, reviews and launch windows before starting. The proposal names the repository owner, payment currency and stages, third-party costs and handover responsibilities.

Questions before you choose

How much does website development cost?

It depends on the work: the number of templates and states, content migration, CMS requirements, integrations, languages, accessibility, animation, testing and handover. We price the documented scope after reviewing those dependencies rather than using a universal per-page rate, and the proposal separates one-time build costs from recurring hosting and software fees.

What's the difference between web design and web development?

Web design decides what the site says, how it's organized and how it looks and behaves. Web development turns those decisions into working code: templates, content management, forms, integrations, performance and deployment. Many problems sit between the two, such as a layout that breaks with real content or a form with no error state, which is why Dardo keeps both in one team or reviews outside designs before building.

Can you build from designs we already have?

Yes. We first review the designs for responsive states, content extremes, interactions and missing loading or error behavior, then agree on implementation acceptance with the design owner. Gaps are listed before the estimate, so nobody discovers mid-build that a state was never designed. If the designs need significant work, we scope that separately rather than improvise it in code.

Which CMS do you use?

It depends on who publishes, how often and what kind of content. For content-led sites, a static Astro build paired with a headless CMS works well: editors write in an editorial interface and publishing triggers a rebuild. When a site is closer to an application, content can live in the app's own database. The proposal names the CMS, explains why it fits and lists any licence or subscription cost.

When do you use Astro instead of Next.js?

We use Astro when most pages are content that can be rendered ahead of time, such as marketing sites, publications and service pages, because it sends little or no JavaScript by default. Next.js fits when much of the interface behaves like an application. Both appear in our published work: Dardo's own site and Superame run on Astro, while A medio tono and Janus Observatory use Next.js.

Who owns the code when the project ends?

The proposal states ownership of code, design assets, accounts and licensed dependencies before work begins. We prefer hosting, domains and the repository under your control from the start, with documented access, so another team could continue without rebuilding. Third-party fonts, services or plugins stay under their own licences, which we list so nothing surprises you after launch.

Do you maintain websites after launch?

It can be included. If Dardo continues supporting the site, the proposal defines what maintenance covers, such as updates, fixes and small changes, and how requests are handled. If not, you receive the repository, documentation and accounts your team or another developer needs to take over. Either way, ownership is settled before launch, not negotiated afterward.

How long does website development take?

It depends on the number of templates and states, the integrations, content migration and how quickly designs and content are approved, so we set the schedule in the proposal instead of quoting a standard figure. Building and testing one representative page first gives both sides an early, concrete read on pace and quality before the remaining templates are built.

Can you work alongside our in-house team?

Yes, on a defined scope. We can build a complete website, implement designs from your own designers or deliver designs for your developers to build, with the split of responsibilities written into the proposal. Before starting we agree on the repository, review process, meeting times and who approves each deliverable, and we work in English or Spanish on a UTC−5 clock that overlaps the US workday.

From the blog

13 more articles

Free tools

  • Website cost calculator

    Pick your market, the kind of site and what's in scope, and see what freelancers, studios and agencies publish for it, with every price linked to its source.

  • Website brief & RFP builder

    Answer a few questions and get a website brief or a formal RFP, ready to send to studios. Export to Word or Markdown. Free, no email.

Sources & further reading

Sources behind this page, with further detail from the original publishers.

Related work & studies

A medio tono: published project interfaceDelivered client website / Music educationA medio tonoInspect a course, the filtered teacher directory and the contact handoff. The dated case records a working customer journey and Dardo's implementation scope.Inspect the project

Define the working system

Inventory templates, content ownership and integrations. Inspect published implementation work, then set acceptance for forms, accessibility, performance and handover.