FirstLab
How to choose a website and what drives the price
Website cost is not “how much to build a page”. It is the cost of getting the start wrong. We break down builders, CMS, and custom code without myths and without a single “correct” stack.
Discuss your projectThree paths
There is no right technology. Only a business goal, time horizon, and risk budget
Website builders
Best fit
Landing pages, quick offer tests, small content scope. Tilda, Webflow, Framer, Wix.
Pros
- Fast launch and lower entry cost
- Client can edit copy without a developer
- Enough to validate demand
Limits
- Limits on integrations and custom logic
- SEO, performance, and vendor lock-in
- Harder to scale for ads, CRM, and growth
CMS and ready-made platforms
Best fit
Blogs, catalogs, typical e-commerce. WordPress, Shopify, and similar.
Pros
- Familiar admin and plugin ecosystem
- Faster to ship a standard store
- Many out-of-the-box scenarios
Limits
- Tech debt, plugin conflicts, security risk
- Cheap start often becomes expensive maintenance
- Custom funnel and analytics cost extra
Custom code
Best fit
Conversion-focused product, custom logic, control over speed and analytics. e.g. Next.js.
Pros
- Flexibility for your business process
- Performance and clean analytics for CPL/CPA
- Lower long-term cost of ownership
Limits
- Higher upfront cost
- Needs a competent team
- Easy to inflate scope without a clear brief
Fit beats trends. A builder is not “bad”, and custom code is not “always better”.
What makes up the price
“From” pricing on our plans is a starting point. Below are the factors that raise or lower the estimate
Discovery and brief
Goals, audience, page structure, priorities. Without this, any “cheap” quote is a lottery.
Conversion UX
Not a “pretty mockup”, but the user path: offer, CTA, forms, trust. This moves CPL more than button color.
Design and responsive
Number of unique screens, states, mobile. More screens means more work.
Development and integrations
CRM, payments, Telegram, pixels, account areas. Each integration adds risk and time.
Analytics
GA4, events, readiness to report CPL/CPA. Without it, ads fly blind.
SEO basics, content, migration
Copy, moves from an old site, redirects. Often missing from “cheap” proposals.
QA, launch, handoff
Forms, pixels, access checks. Training on who edits what.
Support after launch
Who fixes bugs, updates deps, adds pages. In cheap quotes this is usually “later”.
Hidden costs
- Rework from a weak brief and mid-project scope changes
- Rewriting a landing after the first ad tests
- Builder subscriptions, plugins, hosting plan limits
- Lost leads from a slow site or broken analytics
- Switching vendors: onboarding, missing code, redoing work
Competence saves budget
An experienced team closes questions before they become rework. A cheap contractor sells hours; a competent one removes uncertainty
Funnel and CTA upfront
We do not rebuild structure after ads launch. We design for leads from day one.
Analytics events in the brief
Not “we will add the pixel later”. Events are needed on day one or test budget burns.
Speed for paid traffic
A slow site eats CPL. We bake in performance before handoff, not after complaints.
Who owns code and domain
We fix access and rights at kickoff so you do not buy your site back later.
CMS vs manual edits
We agree what you edit yourself vs via the team. No support surprises.
Catalog and logic scale
We ask about growth early: 20 SKUs today vs 2000 next year needs different architecture.
When to choose what
Short scenarios for small and mid-size businesses
Niche test / one offer
Builder or a light landing. Goal: validate demand, not build a platform.
Product landing for traffic
Landing for Meta / TikTok: offer, form, pixels, fast launch. See “Goods landing” under Services.
Catalog and checkout
You need a full online store. Below: when Shopify / CMS fits, when custom does, and what drives the store estimate.
Brand and long horizon
Custom when you need integrations, speed, control, and years of product growth.
Site exists, you need leads
A new site is not always required. Ads and conversion fixes often come first. See ad pricing.
Online store
Catalog, cart, and checkout: when you need a store, which stack to pick, and why a store costs more than a landing
When you need a store vs a landing
A landing is enough
One offer, demand test, narrow assortment, lead form or call instead of self-checkout. Faster and cheaper to validate the idea.
You need a store
Several categories, repeat purchases, online payment, shipping, stock, account area. The customer should complete the path alone.
Hybrid at the start
Ad landing first, limited catalog later. Do not build a full checkout “just in case” before demand is proven.
Shopify / CMS or custom
Shopify or a ready CMS
Typical checkout, standard shipping and payments, familiar admin. Good when the process is close to out-of-the-box and custom is minimal.
Custom store
Non-standard funnel, custom pricing and stock rules, deep integrations, strict speed and ads analytics. Costlier upfront, more flexible long term.
How to choose
Not “what is trendy”, but how well cart, catalog, and logistics fit a ready platform. The more exceptions, the closer to custom.
What makes up the store price
Beyond design and layout, the estimate covers sales processes, not just “pages”
Catalog and product page
Categories, filters, variants (size, color), media, SEO fields. Scope grows with SKU count and attribute complexity.
Cart and checkout
Checkout steps, validation, saved cart, payment errors. Every extra step or exception adds work.
Payments
Payment providers, methods, test / live accounts, status handling and receipts.
Shipping and stock
Carriers, pickup, zones, rates, inventory. “In stock” logic is often harder than a Buy button.
Order admin
Statuses, managers, notes, export. Who handles orders after purchase must be clear before development starts.
Feeds and ads analytics
Merchant / product feed, purchase events, price and stock parity in ads. Without this, Shopping and remarketing fly blind.
Common pitfalls
- Scale: 30 SKUs today and 3000 next year need different catalog and filter architecture
- Promos, coupons, wholesale, and personal prices: if skipped at kickoff, checkout gets rewritten
- CRM / accounting sync: duplicate orders and stock drift
- Returns, cancels, partial payment: rarely in a “cheap” quote, show up in month one
- Speed and Core Web Vitals for product traffic: a slow catalog eats Shopping CPL
Technical essentials you should not skip
Structured data, analytics, speed, and SEO basics. Without them the site “exists”, but search and ads underperform
Structured data (Schema.org / JSON-LD)
Organization, WebSite, BreadcrumbList, FAQ, Product / Offer for stores. Helps search and rich results. Ship it in the first release, not as a later add-on.
Title, description, Open Graph
Unique title/description on key pages, correct OG for social and messenger previews. Without this, links look like a bare URL.
Canonical and hreflang
Canonical URLs against duplicates. For multiple languages: hreflang and a clear locale structure so search does not mix versions.
Sitemap and robots.txt
A sitemap for indexing, robots that do not block important pages by mistake. After launch, verify in Search Console.
Analytics events
GA4 and pixels with lead / purchase / add_to_cart events, not pageview only. Otherwise you cannot measure CPL/CPA and ads optimize blind.
Speed and Core Web Vitals
LCP, CLS, INP. A slow site eats conversion and traffic quality in Ads. Images, fonts, JS: measure before handoff.
Consent and cookies
Consent for analytics/marketing where required. Pixels should not fire before consent if policy demands it. Otherwise risk for accounts and data.
HTTPS and basic security
Certificate, https redirect, spam protection on forms, sensible headers. For stores: safe checkout and admin access.
Forms, errors, accessibility
Clear validation errors, keyboard focus, image alts, readable buttons. Broken forms lose leads before ads even start.
Redirects and 404
On migration from an old site: 301s to new URLs. A 404 with navigation. Otherwise SEO and customer bookmarks die.
CRM and third-party integrations
Leads must land where the team works them. If a direct integration is impossible, we design a workable fallback instead of promising magic
How connections usually work
Native CRM API / webhook
Cleanest path: the site sends the lead into CRM with fields, status, and UTMs. Needs API docs, access keys, and a test account.
Middleware (Make, Zapier, and similar)
When there is no native connector but a webhook or email trigger exists. Faster than custom code, with a subscription and vendor dependency.
Custom connector
Built for a specific CRM or accounting system when the API is complex, unstable, or needs two-way sync. Costlier, fitted to your process.
When integration looks “impossible”
No API, closed admin, manual import only. We design a fallback and lock the process: who moves leads where, and with what delay.
Fallbacks when a direct integration is missing
- Webhook or form → email to a shared inbox with a field template for manual CRM entry
- Scheduled CSV / Excel export and CRM import (fine for low lead volume)
- Interim leads admin on the site: managers see leads and move them into CRM
- One-way only for now: site → CRM today, status sync back later
- Switching CRM plan or CRM itself if API access is business-critical (sometimes cheaper than endless workarounds)
Clarify on the brief before estimating
- Which CRM / service and whether current API docs exist
- Required deal / lead fields and where UTMs come from
- Who owns access and whether a test account is available
- Whether two-way status sync is needed, or “lead arrived” is enough
- What happens if CRM is down: queue, retry, team alert
Questions before kickoff
What people usually ask when choosing an approach and budget
You can, if the job fits the limits. For offer tests a builder is often optimal. If you need custom integrations, stable ads analytics, and long-term growth, a builder becomes an expensive workaround.
Ready to discuss your project?
Tell us what you need now: a website, ads, or the full package. We'll suggest a format without pushing «everything at once».