Open Source Tools We Use Daily at Our Agency

Agency work has a way of stress-testing your tools. A stack that feels fine on one internal project can become painful when you are supporting multiple clients, different hosting environments, handoffs, tight timelines, and production incidents that do not wait for the calendar to clear.

At Paradane, we build custom software, e-commerce systems, SaaS products, API integrations, and automation workflows. That means our day-to-day work moves between frontend interfaces, backend services, databases, deployment pipelines, and debugging sessions. The tools that survive are usually not the flashiest ones. They are the ones that make problems visible, keep teams aligned, and reduce the number of things we have to remember under pressure.

Here are open source tools we reach for constantly, plus where each one fits in real client work.

1. PostgreSQL: boring in the best way

PostgreSQL is still our default relational database for most custom applications. It gives us transactions, constraints, indexes, JSON support, full-text search, row-level security, and mature operational behavior in one package.

The biggest reason we like it is not just performance. It is the way PostgreSQL helps encode business rules close to the data. Foreign keys, unique constraints, check constraints, and transactional migrations prevent a lot of bugs from becoming permanent data problems.

A simple example: if an e-commerce workflow requires one active cart per customer, that should not live only in application code. A partial unique index can enforce it:

CREATE UNIQUE INDEX one_active_cart_per_customer
ON carts (customer_id)
WHERE status = 'active';

That kind of guardrail saves time when there are multiple backend jobs, webhooks, admin actions, and checkout paths touching the same data.

2. Redis: small cache, big leverage

Redis is one of those tools that can be misused easily, but when scoped well it is extremely effective. We use it for short-lived cache entries, rate limiting, background job coordination, session-like data, and computed values that are expensive but safe to rebuild.

A pattern we like is to make cache keys explicit and versioned:

const key = `v2:product:${productId}:pricing:${currency}`;

That sounds minor, but clear key naming makes debugging much easier. When a client says a price, dashboard number, or inventory value looks wrong, you can inspect exactly which computed value is being served and invalidate it without flushing unrelated data.

3. Playwright: testing the actual user path

Unit tests are valuable, but a lot of business-critical defects happen at the seams: checkout flows, login redirects, form validation, third-party scripts, file uploads, and browser-specific behavior. Playwright gives us a reliable way to test those flows.

We especially like using Playwright for smoke tests after deployment. A smoke test does not need to assert everything. It needs to answer: can a real user still do the most important thing?

await page.goto(process.env.APP_URL!);
await page.getByRole('link', { name: /pricing/i }).click();
await page.getByRole('button', { name: /start/i }).click();
await expect(page.getByText(/create your account/i)).toBeVisible();

That one check can catch broken routes, missing environment variables, failed builds, and bad redirects before a client reports them.

4. Docker Compose: repeatable local environments

For many client projects, Docker Compose is still the fastest path to a repeatable development environment. A new developer should not need a 12-step setup document to run the app. They should clone the repo, copy an example environment file, and start the core services.

A typical local stack might include:

• web app
• API service
• PostgreSQL
• Redis
• local mail catcher
• object storage emulator

The goal is not to containerize everything forever. The goal is to remove ambiguity. If everyone is running the same database version, queue, and service ports locally, onboarding and debugging get simpler.

5. Nginx and Caddy: simple edge routing

We see both Nginx and Caddy in production setups. Nginx is battle-tested and extremely flexible. Caddy shines when you want automatic HTTPS and a cleaner configuration for straightforward apps.

For smaller deployments, Caddy can be refreshingly concise:

app.example.com {
  reverse_proxy localhost:3000
}

For more complex routing, caching, and legacy constraints, Nginx is often the better fit. The important thing is to keep edge configuration documented and version-controlled. Reverse proxies are too important to live only in someone's memory.

6. GitHub Actions: useful when workflows stay focused

CI/CD pipelines become frustrating when they try to do too much. We prefer small workflows with clear ownership:

• lint and type check
• run tests
• build artifact
• deploy to staging
• deploy to production after approval

A good pipeline should fail loudly and specifically. If the failure message makes the next action obvious, the workflow is doing its job.

We also like adding scheduled checks for things clients rarely think about until they break: expired certificates, broken links, failed cron jobs, stale dependencies, and API health checks.

7. Sentry-compatible error tracking patterns

Sentry itself is not fully open source in the same way every tool on this list is, but the broader pattern matters: structured errors, release tracking, sourcemaps, and context-rich reporting. Whether using Sentry or another tool, the key habit is to capture errors with enough context to reproduce them.

Bad error:

Payment failed

Useful error:

Payment provider rejected capture
order_id=ord_123
provider=stripe
attempt=2
status=requires_payment_method
release=2026.06.16-4

That extra context can turn an hour-long investigation into a five-minute fix.

8. Prisma, Drizzle, and query builders: choose based on project needs

We do not treat ORMs as religion. Prisma is productive and approachable. Drizzle is lighter and gives excellent TypeScript ergonomics. Sometimes direct SQL is the cleanest option.

The decision depends on the team, schema complexity, reporting needs, and expected lifespan of the project. For a simple SaaS MVP, productivity may matter most. For a data-heavy operations system, explicit SQL and carefully reviewed migrations may be safer.

The rule we follow: the data model should be understandable without running the app.

9. Meilisearch: practical search without overbuilding

Not every project needs Elasticsearch or a managed search cluster. Meilisearch is a great option when a client needs fast, typo-tolerant search for products, documents, listings, or help content without heavy operational overhead.

We have used this pattern often:

1. PostgreSQL remains the source of truth.
2. A background job syncs searchable records.
3. The app queries Meilisearch for search results.
4. The app fetches final canonical records from PostgreSQL.

That separation keeps search fast without letting it become the authoritative database.

10. Local-first documentation with Markdown

The most underrated tool in agency work is still a well-written Markdown file. Architecture decisions, deployment notes, environment variable explanations, onboarding instructions, and incident runbooks should live close to the code.

A useful docs/ folder might include:

docs/
  architecture.md
  deployment.md
  env-vars.md
  runbooks/
    failed-webhook.md
    database-restore.md
  decisions/
    001-use-postgres.md
    002-use-redis-for-rate-limits.md

This is not glamorous, but it prevents repeated explanations and protects the project when team members change.

How we decide whether a tool belongs in the stack

Before adding a tool, we ask:

• Does it remove more complexity than it adds?
• Can the client maintain or replace it later?
• Does it have a healthy ecosystem and clear documentation?
• Can we run it locally or test against it reliably?
• What happens if it fails at 2 AM?

That last question is the most important. A tool is not just a feature. It is an operational responsibility.

Final thought

Open source is a huge advantage for small teams and growing companies, but the value comes from disciplined use. A smaller, well-understood stack usually beats a fashionable stack that nobody can debug.

At Paradane, we help companies turn that principle into production software: choosing the right tools, documenting the tradeoffs, and building systems that can be maintained after launch. If you are planning a web app, SaaS product, API integration, or automation project, the tooling decisions you make early will shape the project for years.