Skip to content

How we work

The technology we use, and how we choose it

We use proven, widely supported tools so your product is easy to maintain and hire for. Here is what we reach for most often, and why.

  • 3 min read
  • Updated September 24, 2026
  • By ExecMedia Team

Technology choices outlive projects. The framework we pick today is the one your team or your next developer will maintain for years. So we favor tools that are mainstream, well documented and widely known, even when something newer looks exciting. That makes your product easier to maintain, easier to hire for and less risky.

We do not have one stack for everything. A content site, a SaaS product and a mobile app need different tools, and your existing systems and team matter too. The lists below show what we use most often, not a fixed menu.

Web front end

The part of the product people see and use in a browser.

  • Next.js and React

    Our default for web applications and fast marketing sites.

  • Tailwind CSS

    Consistent, responsive design without heavy stylesheets.

  • Alpine.js

    Light interactivity for content sites, like this one.

  • WordPress and headless CMSs

    When editors need to manage content themselves.

Backend and APIs

The logic, data and integrations behind the screens.

  • Node.js and TypeScript

    Shared language with the front end for many web products.

  • PHP and Laravel

    Mature, productive and easy to host; a great fit for many business apps.

  • Python

    For data work, machine learning and AI pipelines.

  • REST and GraphQL APIs

    Documented with OpenAPI so others can integrate.

Mobile

Apps for iPhone and Android.

  • React Native

    Cross-platform apps sharing code with React web apps.

  • Flutter

    Cross-platform apps with very consistent rendering.

  • Swift and Kotlin

    Native apps when performance or device features demand it.

  • Progressive web apps

    Installable web apps without an app store.

Data

Where information is stored and queried.

  • PostgreSQL

    Our default relational database for new products.

  • MySQL and MariaDB

    Common in existing systems and PHP projects.

  • Redis

    Caching, queues and fast temporary data.

  • Vector databases

    For semantic search and RAG, such as pgvector or Qdrant.

AI

Models and tools used in products and in our own workflow.

  • Large language models

    Claude, GPT and Gemini models, chosen per task after testing.

  • Open-weights models

    Llama, Mistral, Qwen and others when data must stay in-house.

  • Model Context Protocol

    Standard, permissioned connections between AI and your tools.

  • AI coding assistants

    Such as Claude Code, used by our engineers with review on every change.

Hosting and operations

Where products run and how they are kept healthy.

  • Cloud and VPS hosting

    AWS, Google Cloud, DigitalOcean or a VPS, depending on needs and budget.

  • Docker and Coolify

    Container-based deployments that are easy to move between hosts.

  • GitHub and CI

    Version control with automated tests and deployments.

  • Monitoring

    Error tracking, uptime checks and logs from day one.

How we choose for your project

We start from your situation, not our preferences. Who will maintain the product after launch? Does your team already know a language? Where will it be hosted, and what does that cost? Are there rules about where data may be stored? How fast must it be, and how many users will it have in the first year?

For common decisions we have written comparisons: Next.js vs Laravel, PostgreSQL vs MySQL, React Native vs Flutter and WordPress vs a custom website.

AI tools in our workflow

We use AI coding assistants and large language models throughout development, as described in AI-accelerated development. These tools speed up our work; they are never required to run your product. If your product includes AI features, the models and providers are chosen for that feature, documented, and swappable. See our AI model directory for the options we evaluate.

What we avoid

  • Niche frameworks with small communities, unless there is a strong reason.
  • Proprietary platforms that make it hard to move your product later.
  • Adding tools because they are fashionable. Every dependency must earn its place.

Whatever we choose, you own the code and the accounts. Read security and IP ownership.

Keep exploring

Start a project

Tell us what you want to build. We will show you a faster path.

Send a short brief. We reply with questions, a suggested plan and an estimate you can compare with other offers.

Your privacy choices

We use necessary storage to run this site. With your permission we also use Google Analytics to see which pages help people, and load maps from Google. You can change this at any time. Read the cookie policy.