Frequently Asked Questions

The price depends on four factors: how complex the functionality is, how much custom design work is involved, integrations with external systems (CRM, payment gateways, ERP, inventory), and security/performance requirements. A simple template-based brochure site costs far less than an online store with custom catalog logic — that's not padding, it's simply a different amount of engineering work.

The word "website" can hide very different products:

• Template vs. custom build — a template is cheaper but limits flexibility.
• Freelancer vs. team — a freelancer has lower overhead, but no backup if they're sick or on leave, and no dedicated QA tester.
• Whether testing, SEO basics, and security are included — cheap quotes often skip these, and they resurface later as "extra work."
• Whether warranty support is included after handover.

If a quote is far below market rate, it's worth asking exactly what's included.

The price of a website isn't "one person's hours" — it's a full cycle: analysis, design, front-end build, programming, testing, and often integrations plus training on the admin panel. Compared to a ready-made template or a DIY site builder, yes, the gap is real, because these are different products in terms of depth of work. We try to break the estimate down by line item so it's clear what you're actually paying for, rather than just handing over one total number.

Compare the scope behind the number, not the number itself. It's worth asking both sides: is custom design included, or is it a template; who handles testing, and on how many devices; is basic SEO groundwork and security included; is there a warranty period, and what does it cover; who owns the source files and access credentials after payment. Often "half the price" simply means half the scope, not a better deal.

UX/UI design (wireframes, mockups), front-end build, back-end programming (logic and integrations), copywriting (if needed), and testing. Different agencies weigh these differently — some bill copywriting separately, others bundle it into the package.

Yes, that's standard: a deposit before starting (usually 30–50%), payments at the completion of key milestones (design, development), and a final payment after acceptance and launch.

Usually these are separate costs paid directly by the client to the registrar and hosting provider — that way ownership of the domain and hosting account stays with the client from day one, rather than being tied to the agency.

Typically this covers: CMS and extension updates (security), backups, uptime monitoring, minor content edits, and advisory on further development. High-traffic projects also need performance monitoring and hosting scaling.

A simple brochure site — 1–3 weeks; a mid-level site with a catalog — 4–8 weeks; a portal or online store with integrations — 2–4 months or more. The exact timeline is fixed once the spec is approved.

Requirements analysis → wireframe/prototype → design → front-end build → programming and integrations → testing → launch → handover of all access credentials to the client.

Through regular check-ins showing work in progress (roughly every 1–2 weeks), access to a staging server, and a dedicated communication channel.

A logo and brand guidelines (if available), copy or a brief for the copywriter, photos/illustrations, access to any existing systems, and a list of required integrations.

It's possible, but "nice" means something different to everyone, so a first step is still needed — it'll just be shorter and based on examples rather than a long questionnaire. We usually ask for 3–5 references (sites you find visually appealing), a couple of sentences about who the site is for, and any brand materials you already have. Then we show 1–2 design directions before diving into detail — that clarifies taste faster than a written spec ever could.

• SaaS builders — a fast start for landing pages without complex logic, but you're locked into the platform.
• WordPress — the largest plugin ecosystem and a low barrier to entry. The downside: the quality and security of third-party plugins vary widely, and stacking too many of them slows the site down over time.
• Joomla — a stricter, more predictable architecture out of the box (see the next question).
• Drupal — the most flexible option for complex enterprise systems, but it needs a more experienced team and costs more to build.

1. Built-in multi-level access control (ACL). Permissions by user group, category, and even individual items work out of the box, unlike WordPress, where this usually needs a plugin. Useful for sites with multiple departments or contractors who need limited access.
2. Multilingual support without third-party plugins. Built into the core, whereas WordPress almost always needs a paid plugin (WPML, Polylang Pro).
3. A stricter content structure. Categories, tags, and content types are organized hierarchically at the core level. Useful for catalogs, portals, government sites, and multi-branch organizations.
4. Fewer but more consistently reliable extensions. A smaller ecosystem than WordPress's, but with fewer low-quality or abandoned extensions as a result.
5. Common in the public sector and NGOs. Thanks to its ACL and stability, many European government and educational institutions run on Joomla specifically.

An important caveat: Joomla isn't "better overall" — it's better for a specific class of projects: sites with complex content structures, many user roles, and a need for multilingual support without paying extra for plugins. For a simple blog or landing page, WordPress or a SaaS builder is usually the smarter choice.

Yes, we work with the client's choice as long as the platform genuinely fits the task. If we see that the chosen CMS is a poor fit for your goals (for example, a platform with weak product management chosen for a large e-commerce catalog), we'll flag it upfront and explain the risk — but the final call is always yours.

The core engine itself isn't less secure — the issue is usually the ecosystem: with such a huge number of third-party plugins of varying quality, the statistical risk of installing a vulnerable component is higher. But in both cases, security depends about 90% on how disciplined you are with updates and configuration, not on the CMS itself.

Yes — responsive design is standard today: most sites get over half their traffic from mobile devices.

Yes — every modern CMS provides an admin panel for editing content without coding. How convenient that is depends on how thoughtfully the editable fields are set up — worth discussing at the spec stage.

The baseline: regular CMS and extension updates, an SSL certificate, anti-spam protection on forms, login attempt limits on the admin panel, and backups. For higher-stakes projects — a Web Application Firewall and periodic security audits.

Basic SEO groundwork — clean URLs, meta tags, load speed, heading structure, a sitemap — needs to be built in from the start; retrofitting it later costs more. Full-scale promotion (content strategy, link building) is usually a separate service.

Many studios run a brief competitive review before designing the site structure — it helps avoid repeating others' mistakes. How deep that analysis goes depends on the service package.

PPC and social media setup usually isn't included in the base website package by default, but it's often offered as a separate service after launch.

A website by itself is a tool, not a traffic source. Sales happen when the right people arrive at the site — through ads, SEO, social media, email, or offline channels. We can build the site to convert well (clear forms, fast load times, proper analytics), but promising specific sales numbers "starting tomorrow" wouldn't be honest — it depends on dozens of factors, including your niche, competition, and promotion budget.

Most projects come with a warranty period (1–3 months) during which fixing development-side bugs is free. Ongoing technical support is arranged under a separate agreement.

The most common causes: an expired domain or hosting plan (renewal missed), an expired SSL certificate, a plugin/CMS auto-update conflicting with another component, a change on an external service you're integrated with (payment gateway, maps API, social login), or the hosting plan not handling a sudden traffic spike. The good news: most of these are identified within minutes of diagnosis and fixed quickly — that's exactly what monitoring and a support agreement are for.

After full payment, the client should receive: hosting and domain access, the source code, design files, and admin passwords. This is worth spelling out explicitly in the contract — it's not uncommon on the market for an agency to withhold access as leverage in a dispute.

Short and without the sales pitch: we match the technology to the actual task instead of selling everyone the same solution; we break the estimate down by line item instead of handing over one number; we spell out in the contract that all access and source files transfer to the client after payment; and we flag risks in a client's own choices (like a poor-fit CMS) upfront, before money is spent — not after. We don't promise "a million sales in a week." We promise an honest estimate of timeline, budget, and what's actually achievable.