Development and support of web applications and websites

Why choose full-cycle website development?

The client comes with the task "we need a website" — and in the first conversation it becomes clear what lies behind it: an online store with 1C synchronization, a corporate portal with role-based access, a SaaS platform with multi-tenant architecture, or a public landing page with A/B tests. These are fundamentally different tasks — in architecture, stack, timelines, and complexity points. Over more than 8 years of work, we have completed over 150 such projects — from simple landing pages to high-load platforms — and we know where bottlenecks actually occur.

Below is how we make technical decisions for each direction and what we guarantee at each stage.

Why choosing a rendering strategy is the main decision at the start?

Most modern interfaces are built on React or Vue. The choice between them is almost never critical — what matters more is the choice of rendering strategy: SSR, SSG, ISR, or SPA.

For public sites with SEO requirements, we default to Next.js App Router or Nuxt 3. ISR allows caching catalog pages on the CDN and regenerating them on trigger — without full SSR on every request. This gives TTFB < 80 ms even on a catalog of 200,000 SKUs.

For admin panels, dashboards, CRM interfaces — SPA on Vite + React is sufficient and faster in development. TypeScript is mandatory: without it, refactoring at scale is painful.

Bundles are a constant source of problems. An unnoticed moment.js in dependencies adds 230 KB gzip. lodash instead of lodash-es breaks tree-shaking. We use @next/bundle-analyzer or vite-bundle-visualizer on every project — before deployment, not after.

What problems does full-cycle development solve?

Backend: Laravel, Node.js, Go, Django

Laravel is our main framework for business applications. Octane with Swoole holds 8,000–12,000 RPS on a single m5.xlarge server with proper configuration — this covers 95% of tasks without horizontal scaling. For Node.js, we choose Fastify over Express: 2–3 times faster on cold requests, better TypeScript integration.

Database: PostgreSQL as the foundation

PostgreSQL is the primary database. For caches and queues — Redis. MongoDB is used only for specific tasks: storing unstructured documents or geodata. PostgreSQL's ACID compliance and extensibility are trusted by the largest systems (PostgreSQL documentation).

N+1 query is the most common cause of performance degradation — about 80% of slow page loads stem from it. On a catalog page with eager loading with(['category', 'images', 'attributes']) it's not a problem. But adding custom labels or aggregated ratings without withCount, loadMissing, or a dedicated query object leads to 300+ queries per page. We cover this with tests via Laravel Debugbar and Telescope in the dev environment.

Indexes are a separate story. Composite index on (status, created_at DESC) for filtered feeds. Partial index for soft-deleted records. GIN indexes for JSONB fields and full-text search. Without this, any ORDER BY on a large table becomes a seq scan. On a table with 500,000 rows, proper indexing reduces a full scan from hundreds of milliseconds to under 5 ms.

CMS and Content

For projects where editors work with content independently, the choice of CMS depends on the complexity of the data structure:

• WordPress — for simple corporate sites and blogs. Fast, familiar, huge plugin ecosystem. We don't demonize it — it solves its tasks well. But for e-commerce with non-standard business logic, it's a poor choice.
• Headless CMS (Strapi, Directus, Payload CMS) — when flexibility in data structure is needed and the frontend is entirely on React/Vue. API-first, content via REST or GraphQL, frontend deployed separately on Vercel or custom Nginx.
• Custom CMS on Laravel — for projects with unique workflow, roles, content versioning requirements. More expensive to develop, but fully tailored to the task.

E-commerce: catalog performance and integrations

Online stores are a separate direction with high technical intensity. Important aspects:

• Catalog performance under large volumes (Elasticsearch or PostgreSQL full-text search)
• Correct checkout handling races when reserving products
• Integrations: 1C, MoySklad, payment gateways (Stripe, YooKassa, ERIP)
• Faceted filtering without N+1

For small stores, WooCommerce or OpenCart with customization is sometimes enough. For stores with non-standard logic (subscriptions, rentals, B2B price lists) we write from scratch on Laravel.

SaaS platforms: multi-tenancy, billing, feature flags

SaaS is not just a "site with authentication". It's multi-tenant architecture, billing, onboarding, feature flags, rate limiting, audit logs. Each of these blocks has non-trivial implementations. Multi-tenancy approaches are described in detail by Martin Fowler.

Multi-tenancy at the database level: shared schema (tenant_id on each table) vs separate databases. The first approach is easier to maintain, the second provides data isolation — the choice depends on client security requirements.

Billing via Stripe with webhook handling — events must be processed idempotently. invoice.payment_succeeded may come twice.

AI integrations: LLM, RAG, streaming

Tasks that didn't exist before have emerged: integrating LLM into the product, AI search, content generation, chatbots with RAG. We work with OpenAI API, Anthropic API, Ollama for local models, as well as vector databases (pgvector, Qdrant) for semantic search.

An important nuance: streaming responses from LLM require proper implementation of Server-Sent Events or WebSocket on the backend and correct chunk handling on the frontend. Without this, UX suffers — the user waits for the entire response instead of seeing it gradually.

SEO and Core Web Vitals

SEO is built into the architecture, not added at the end. SSR/SSG for public pages, correct canonical, structured data (JSON-LD), sitemap with priorities.

Core Web Vitals — metrics that actually affect ranking:

• LCP (Largest Contentful Paint): target < 2.5 s. Common failure cause — hero image 3–4 MB without srcset and without loading="eager" + fetchpriority="high" on the first screen.
• CLS (Cumulative Layout Shift): target < 0.1. Dynamic banners without reserved space, fonts without font-display: swap — typical sources.
• INP (Interaction to Next Paint): target < 200 ms. Heavy event handlers, synchronous JS on main thread, non-optimal React re-renders.

We measure this in Lighthouse, PageSpeed Insights, and via Playwright in CI — not only on desktop but also on emulated 4G mobile. 2–3 times faster load times on mobile vs. poorly optimised competitors are common after these fixes.

How do we estimate deadlines for full-cycle development?

Stages of work

1. Discovery — requirements gathering, analysis of the current system (if any), identification of integrations, creation of ERD
2. Design — architecture, stack selection, wireframes or Figma prototype
3. Design (UI) — UI kit, responsive design, design system in Figma
4. Development — sprints of 1–2 weeks, demo after each
5. Testing — unit, integration, e2e (Playwright), load testing (k6 or Locust)
6. Deployment — Docker + Nginx, CI/CD via GitHub Actions or GitLab CI, monitoring via Sentry + Grafana
7. Support — SLA, dependency updates, scaling

Timeline estimates

Cost is calculated individually after decomposition. The estimate is influenced by the number of integrations, volume of user roles, load requirements, and availability of existing design. Our solutions allow reducing hosting costs by 30–50% — this translates to significant annual savings for an average project.

Typical mistakes we encounter in existing projects

Common pitfalls in full-cycle development:

• Missing indexes on foreign keys. Laravel didn't create them automatically until a certain version. On a 500K row table, a JOIN without an index results in a seq scan on every query.
• JWT without a revocation mechanism. Access token lives 15 minutes — okay. But without a blacklist or rotation of refresh tokens, a compromised token works until it expires.
• Lack of rate limiting on API. Without throttling, the /search or /export endpoint can easily be brought down by a random script.
• Deployment without a rollback strategy. If a deployment breaks production, a fast revert mechanism is needed. Blue-green or at least tagged Docker images with the ability to roll back in 2 minutes.
• Logs only in stdout without aggregation. Sentry for exception tracking + structured logs in Loki or CloudWatch — minimum for a project you plan to support.

What you get (deliverables)

Upon project completion, we deliver:

• Documentation: architectural diagrams, ERD, API description (OpenAPI/Swagger), deployment guide
• Source code in a private repository (GitHub/GitLab) with main branch protection and code review
• Access: to hosting, control panel, monitoring (Sentry, Grafana), CRM and CMS (if applicable)
• Training: 2–3 sessions for administrators and content editors
• Support under SLA: warranty period of 1 month (critical bugs — 4 hours, others — 24 hours)

Experience and guarantees

We have been in the development market for 8 years with over 150 completed projects. We fix SLA in the contract; if deadlines are violated, we compensate with a discount on further maintenance. We hold partnership statuses for Laravel, React, and cloud providers (AWS, Selectel). Licensed software, non-disclosure agreement (NDA), and personal data processing in compliance with Federal Law No. 152-FZ guarantee security.

Our typical client saves 30–50% on hosting costs compared to their previous setup. That's thousands of dollars annually.

Get a precise estimate for your project — contact us to start a technical discovery. Order a full-cycle website development — get a consultation from an engineer and an accurate timeline estimate.