A Framework for Adopting New Tech on Client Projects
For an agency, evaluating whether to introduce a new technology is a recurring decision with unusually high stakes. Unlike a product team that can absorb the cost of experimentation, an agency is spending a client's budget and time. Once a project crosses a certain threshold, reversing course becomes nearly impossible. Tight timelines, rigid budgets, and the need to eventually hand the codebase back to the client mean every technology choice has to be measured carefully.
Every engineer knows the experimentation phase is the fun part. There is a natural euphoria in learning something new, especially when a greenfield project offers a clean slate. But with experience comes the knowledge that every technology has flaws — you just haven't found them yet. As Joel Spolsky put it, you have to live with a technology for a year or two before you truly know whether it's good enough or whether it won't work at all.
That uncertainty is exactly where an agency tech lead does not want to be near a deadline. When evaluating any new piece of technology for a client project, it helps to break the decision into three lenses: The Technology, The Developer Experience, and The Business. Each has its own criteria that should be satisfied before committing real project time.
The Technology Itself
The first lens is the raw technology. This is where engineers are most comfortable, but leadership requires looking at more than just features. The technology must solve a real problem, not just be an interesting alternative. It has to be reliable in production, performant under realistic load, and mature enough that major issues are unlikely to surface mid-project.
Security and compliance are equally important. A database handling client data needs clear answers on encryption, access control, and data residency. There must be a credible path for backups, disaster recovery, and, critically, migration — both in and out of the technology. If the client's future team needs to move away from it, how painful will that be?
Vendor lock-in is considered with brutal honesty. For an agency, the success of the project is not measured by how well the technology fits a single use case, but by how well it serves the client long after hand-off. That means understanding what it takes the technology to maintain, scale, and operate once the agency team is out of the picture.
The Developer Experience
Developer experience is a lens that separates a technology that gets adopted from one that gets abandoned after a prototype. The happy path for a new tool is intuitive and joyful, but that's often the shallow part of the learning curve. What matters more is how the technology behaves when a developer needs to escape the happy path.
The framework here asks for strong documentation that covers edge cases, not just quickstarts. It asks for a gentle learning curve so team members can become productive in days, not weeks. Sessions with the technology should be recoverable errors, clear logs, and ways to debug when things don't work as expected.
Tooling matters too — whether the technology integrates with the IDE or supports a local development setup that mirrors production. A particularly important test is whether a developer can make a mistake and still figure out how to fix it quickly. If the technology keeps those moments opaque, it will burn billable hours at the worst possible time.
The Business Case
The final lens is business viability. This looks at the company or project behind the technology. Has it been around long enough to be stable? Does it have strong adoption, a healthy community, or paying customers? A technology backed by an unstable vendor is a risky bet for a client who may need to maintain the project for years.
Cost is evaluated at two levels: licensing and the operational load. The pricing model has to fit a variety of project sizes and scale predictably as the client grows. Total cost of ownership includes the time required to learn, the cost of infrastructure — whether managed or cloud-based — and any extra moving parts the project needs to operate.
For an agency, maintenance costs are a hidden budget item that must be minimized. Every additional service, cluster, or config that must be babysat after go-live is a liability. The ideal new technology should be one that reduces the team's operational burden rather than adding new responsibilities.<
Does It Meet the Functional Bar?
Before considering how any new technology fits into a workflow, it has to clear the first hurdle: does it actually solve the problems it claims to solve? That means comparing it against what we already use and asking hard questions:
- Does it at minimum do what the existing solution does?
- Where is it genuinely better, and where is it worse?
- What would it take to overcome the shortcomings?
- Can it replace multiple tools at once?
- How stable is the project itself?
Why We Are Looking At All
Rarely do we switch technologies because an existing solution is fundamentally broken. Usually, something newer makes an already-solved problem easier, faster, cheaper, or more stable. React won us over versus direct DOM manipulation because stateful frontends became dramatically easier to build with data structures. TypeScript earned a place because it improved code stability and maintainability. The motivation is often just staying current and finding efficiency gains.
For databases, our motivation was the serverless model. We had already seen serverless applications reduce operational overhead, but our data layer had not benefited. Services like Amazon Aurora, Fauna, Cosmos, and Firebase apply serverless principles to databases, and we wanted to know if the leap made sense for us. The aims were lower operational overhead and faster development.
Before evaluating any product, you have to take inventory of your why. Understanding what problems you are actually trying to improve is critical; otherwise, every evaluation lacks context.
What We Were Using
Across past agency projects, we used numerous databases, but three dominated: PostgreSQL, MongoDB, and Firebase Realtime Database. Each had semi-serverless options, but gaps in those offerings left us open to newer alternatives.
PostgreSQL has always been our choice for larger, long-term work. It is battle-tested, ACID compliant, and supports normalized relational data, transactions, and JSON columns for NoSQL-style use. The tooling and ORM ecosystem is vast, and open-source licensing means no vendor lock-in. That said, we moved away from it as Node.js became our preferred backend: Node ORMs felt lackluster, local setup and migrations were friction points, and NoSQL felt more natural in a JavaScript/TypeScript runtime, even for classic e-commerce-style relational workflows.
MongoDB, particularly via Atlas, became our go-to once Node was standard. Mongo's flexible documents were a huge win for agency work where last-minute data requirement changes are inevitable; no more managing stacks of temporary migration files. Atlas, however, is only "semi-serverless": you provision instance size and memory manually and must monitor when to scale up. For a long time, Mongo also lacked ACID transaction support, which kept us on Postgres for e-commerce. Its query language and native JSON support did provide speed and efficiency unmatched by our relational experience.
Firebase Realtime Database filled a specific niche: short-lived projects with simple data requirements where unknown scale and limited budgets made pay-as-you-go attractive. But Firebase pushed us further from relational modeling. Keeping data structures flat required heavy duplication, updates in multiple places, or complex reference-joining query code. We liked Firebase; we never loved its query language or documentation.
Both NoSQL options shared a similar focus on denormalized data. Without robust transactions or efficient joins, workflows that were trivial in a relational database became convoluted application-layer code. MongoDB had the superior API; Firebase had the superior operational model. We were looking for the flexibility and ease of NoSQL wrapped in the robustness and relational support of SQL.
Defining Our Ideal
With the past mapped out, we could define the minimum bar for a new solution. It needed to be:
- Operationally serverless with on-demand scaling
- Flexible (schemaless) in its data modeling
- Free of migration files and dependency on ORMs
- ACID compliant with transaction support
- Capable of supporting relationships and normalized data
- Compatible with both serverless and traditional backends
A product need not nail every target; the right combination is enough if it fills the gaps where existing tools leave us short. For a long time, choosing schemaless meant surrendering acid transactions, much like how template-level TypeScript validation forces you into React with TSX while Svelte or Vue only offer it partially. Value shifts per project, and adoption just requires ticking the most important boxes.
That balance is where Fauna came into play. As a serverless database, it advertises on-demand scaling with global distribution. It is schemaless but also provides ACID transactions and relational queries for normalized data. It works with both serverless functions and traditional backends, with client libraries covering major languages. The built-in auth workflows and multi-tenancy support are notable strengths that could swing a close decision.
Balancing the Weaknesses
No evaluation stops at strengths. Two concerns stood out with Fauna. First, it is not open source, which introduces vendor lock-in and exposure to business shifts out of our control. Open source gives you the option to move vendors or contribute back if needed. For an agency, lock-in is dangerous because changing databases mid-project or years into a client relationship is painful and often offloaded onto the client.
Second, Fauna leans heavily into JAMstack. We like JAMstack, but most of our work is traditional web applications. Past experience with a host that went all-in on JAMstack left us migrating a large segment of sites. We needed confidence that traditional use cases remain fully supported. It appears they are: the serverless workflows actually complement classic applications nicely.
At that point, research is done. Working in an agency, you don't get weeks to prototype multiple solutions within a crowded evaluation phase. You get a few days — or a side project — to narrow the field to one or two candidates and start writing code. The viable options were few, and it was time to test them hands-on.
Judging the Developer Experience
Developer experience is inherently subjective and varies team to team. Before judging it, you must first decide what characteristics matter most to your organization. For agencies, two bottlenecks dominate this evaluation:
- Setup time and configuration
- Learnability
Both affect the long-term viability of a new technology, but in different ways. Keeping transient teams of developers in sync is a headache. Tools with heavy upfront setup costs and configuration burdens are notoriously difficult for agencies to work with. Learnability, meanwhile, determines how easily developers can grow with the technology.
Setup Time and Configuration
Agencies have little patience for configuration. They want sharp, ergonomic tools that get them to the business problem quickly. Complex local setups that fail at random points are a nightmare — the conventional wisdom often becomes "don't touch anything" once things work. While some developers enjoy tinkering with every piece of their environment, agency engineers generally disdain this in their day-to-day work. When on a deadline, they prefer tools that just work consistently over tools that can be configured to individual taste.
This is the inherent appeal of serverless. Serverless tools rely more heavily on proprietary services, trading flexibility for stability and focus. A cloud platform that owns setup and configuration eliminates local environments, deployment pipelines, and a host of decisions. When migrating off a platform feels necessary at the outset, that is usually a bad sign.
For databases, the set-it-and-forget-it setup is ideal when client needs are ambiguous. Clients are often unsure how popular an application will be, and sometimes call in a panic when they need to scale. In the past, agencies had to factor redundancy, data replication, and sharding into scopes of work — an impossible situation to prepare for when you don't know what will be needed. Serverless databases make these concerns disappear:
- You never lose data.
- No need to replicate data across a network.
- No provisioning of larger databases or machines.
For development teams this is a huge win: fewer fire drills, less monitoring, and less context switching. The team only focuses on the business problem while the technical architecture and scale are always managed.
Learnability
Learnability is a classic UX measure that applies equally to developer experience. The question is not whether a system is apparent on first try — technology rarely is — but how easily a new user can learn and master it over time. Powerful tools will have a learning curve. What matters is that documentation covers the most common use cases and that knowledge compounds quickly across projects.
What agencies look for is how new tools let developers leverage existing knowledge. For serverless databases, there is virtually zero learning curve for cloud setup and deployment. What matters more is the data modeling experience. When a database forces you to rethink how you model data from the ground up, that creates cognitive friction. For example, Firebase, MongoDB, and DynamoDB encourage denormalized data rather than joins, forcing developers to think in terms of access patterns rather than business entities. Databases that preserve relational concepts and normalized modeling let teams apply years of mastered skills to new setups — the only new parts to learn being indexes and a new query language.
A strong sign of adoption is when the team starts asking whether existing tools integrate with the new technology. When a team seeks ways to incorporate a tool into more projects, that signals it has reached a level of desirability that makes it a winner.
The Business Perspective
Any new technology must meet business needs. Key questions include:
- How easily can it be priced and integrated into support plans?
- Can we transition it to clients easily?
- Can clients be onboarded to the tool if needed?
- How much time does the tool actually save?
Serverless fits agencies well because the need for DevOps specialists is limited. Agencies typically hand off projects when done or support them in a limited capacity long term. Full-stack engineers far outnumber DevOps needs, so DevOps is often staffed with contractors rather than hired full time. Managed platforms like Heroku allow existing staff to debug most issues without a dedicated DevOps engineer. Databases are no exception — services like Mongo Atlas or Heroku Postgres make the process easy. As stacks move toward serverless tools like Vercel, Netlify, or AWS Lambda, database needs evolve accordingly. Serverless databases like Firebase, DynamoDB, and Fauna integrate well with serverless apps while freeing the business from provisioning and scaling. They also work well for traditional applications, where you can still leverage serverless efficiencies at the database level. Learning a single database that applies to both worlds is more productive than context switching.
One major downside is pricing for clients. Traditional architectures with flat-rate tiers translate easily to predictable client rates. Serverless pricing is ambiguous — finance people do not like hearing charges of fractions of a penny per read beyond a certain threshold. Engineers building applications often do not know what usage will be, making it hard to translate variable costs into fixed numbers. For SaaS products, pay-as-you-go models are great; for agencies, accountants want concrete, predictable numbers.
Providers also differ in how easily they support breaking down usage per application. The Heroku platform makes this easy by creating separate pipelines and teams, and allows entering a client's credit card directly within the same dashboard. Other serverless tools are more difficult: Firebase supports splitting payments by project, but with databases like Fauna or DynamoDB, that is not possible. Agencies must monitor usage in the provider dashboard and, if a client leaves, transfer the database to their own account.
Serverless tools offer business opportunities in cost savings, management, and process efficiency. However, they often challenge agencies on pricing and account management. Cost calculators and creating separate client accounts for direct payments are common workarounds.
What The Evaluation Settled
Applying the three filters — technology, experience, and business — to serverless databases produced a predictable set of trade-offs. The technology itself proved robust, but the deciding factors for the team were operational and practical. After weighing the alternatives, the agency adopted Fauna, finding that its strengths outweighed the difficulties identified during the evaluation.
On the technology side, Fauna satisfied every requirement in the agency’s filter. From an experience standpoint, the near-total absence of configuration was a major selling point, along with the ability to reuse existing relational data-modeling knowledge. The business case was more nuanced: serverless delivered clear efficiency and productivity gains, but pricing and account management remain sticking points. Those concerns were not enough to offset the benefits found elsewhere.
Rolling Out A New Database At An Agency
Adopting a new technology carries inherent risk, and agencies have less room for error than product companies — a failed rollout on a client engagement is not something you get to redo. The mitigation strategy was to start small. Initial projects were either internal tools or small external ones, letting the team build familiarity before applying the database to larger, more complex work. Only after the technology had proven itself on similar use cases did the agency scale its use.
Patience is required here. A technology can take up to a year before it becomes a standard part of most project stacks. The goal is steady experimentation — pushing the agency toward new tools without compromising the stability of what goes out the door.
Final Verdict
Fauna has become both a go-to choice for smaller serverless projects and a viable option for more traditional, larger backend applications. The learning curve is gentle, the community is responsive, and the team reports levels of productivity they had not seen with existing databases. It is worth trialing on an upcoming project, provided you enter with a clear view of what matters to your organization and a plan for phased adoption.
References And Further Reading
- Serverless Database Wishlist - What’s Missing Today
- Relational NoSQL: Yes, that is an option
- Concerning toolkits — On the merits of zero configuration for developer experience
