How (and when) we evaluate new technology at CobbleWeb

“Any sufficiently advanced technology is indistinguishable from magic.”

– Arthur C. Clarke

Well, almost. At CobbleWeb, we believe that while technology can feel like magic, choosing the right tech stack for a project should be anything but mystical. It’s a deliberate, practical process – less wand-waving wizardry and more Sherlock Holmes with a laptop.

If you’re a budding software engineer looking to join our team, you might wonder: “Will I get the chance to work with new technologies?” The answer is yes – but with a twist. We’re not chasing every shiny new framework that trends on CODE Magazine for five minutes. We believe in using the right tool for the job, which sometimes means staying classic and sometimes means going cutting-edge.

Let’s walk through how and when we evaluate new technology at CobbleWeb – and why we don’t reinvent the wheel (unless the new wheel actually flies).

TLDR: check out the short version in the slide presentation if you are in a hurry 👇

We’re pragmatic, not dogmatic

There’s a common misconception in tech circles that innovation means starting over. Rip it up! Rewrite it all in Rust! Rebuild your stack in Elixir overnight!

No thanks.

At CobbleWeb, we’ve built a reputation on delivering powerful, scalable online marketplaces – from parking platforms like MobyPark (now acquired by a major Dutch operator), to fintech innovators like SoShop (acquired by AVIA), to ticketing disruptors like FanPass, which pulls in millions in annual revenue.

Here’s the thing. Marketplace platforms, by and large, share a consistent core of features. Product listings, payment processing, messaging, user reviews are the familiar gears behind the machinery. Reinventing these every time isn’t innovation. It’s inefficient. 

That’s why we’ve honed a core technology stack that’s tried, tested, and lovingly debugged. You can explore it here. It’s helped ambitious startups like Nestify scale across six countries, while keeping their code flexible and maintainable.

Still, we’re not dogmatic. Our stack evolves. When a project demands it, we adapt. But we start from what works and build from there.

Aligning tech with business goals

One of our mantras at CobbleWeb is: “Technology should serve the business, not the other way around.” That’s why we place a big emphasis on the discovery phase of every project.

During Discovery we dig into the client’s business model, user journeys, and key differentiators. That’s when we start to see whether our existing stack fits or if something new is needed.

Why might we explore new tech? Some common reasons include:

• Support for a unique functionality: Maybe the client wants a real-time logistics map with hyperlocal weather overlays (we’re not making that one up).

Case in point 👇

Property management platform, Nestify, needed to automate property access for cleaners in order to scale their platform. We investigated various IoT solutions, which led to the implementation of two new technologies: KeyBox and KeyNest. 

KeyBox sends a one-time code to the property cleaners once a shift is created with which to open a key lockbox. When the keys are returned to the lockbox the code expires. ​KeyNest uses collection points (stores) close to the property. A collection code is sent to the cleaner, who exchanges it for the keys. Property managers are automatically notified when keys are collected or returned.

• Speed of implementation: Sometimes, a library or framework can fast-track development without sacrificing quality.

Case in point 👇

We initially wanted to use React Native for a restaurant delivery app, but were worried that it would take too much time to implement. Caner, one of our full-stack engineers, was nominated to do some research on the Ionic framework. His Proof of Concept showed that it would take us 30% less time to create the frontend, since we could re-use more components from the main platform. You can read more about Caner’s CobbleWeb journey here.

• Cost-efficiency: This is especially valid for early-stage startups that need to watch their runway. We are busy solving this challenge with ShareWise – a plug-and-play modular PaaS solution for marketplace startups. It allows them to test their initial assumptions at a fraction of a custom solution’s cost.
  
• Client request: Occasionally a client insists on using a particular tech – though we’ll always advise if that tech might cause migraines later.

Case in point 👇

The marketing team at Affordable Art Fair wanted tools that could help them drive the right users to the platform. We built a data pipeline with Snowplow (collect & model data), Amazon Kinesis (capture & analyse streaming data) and Google Merchant Center, which tracked specific user events, such as which product categories were viewed or which artists were added to wish lists.

The data helped Affordable Art Fair’s team to create more targeted Google, Facebook and Pinterest ads, which increased engagement 2 – 3 times.

• Significant improvement: A new technology might truly outperform what we’ve been using and if so, it deserves a seat at the table.

Case in point 👇

For a recent project, Aref, one of our senior full-stack engineers, had to get to grips with Terraform, AWS’s infrastructure-as-code tool. This helped us improve the automation of cloud infrastructure tasks such as provisioning and configuration of resources. You can read more about Aref’s CobbleWeb journey here.

The process of tech evaluation: When, Who, and How

Now for the good stuff: How does new tech get evaluated at CobbleWeb? Is it one engineer shouting “Check out this cool framework!” in Slack? Nope, but that does happen 😀

When?

Evaluation happens during the Discovery phase. Specifically when we’re documenting the technical specifications for a new project or feature. Every major piece of functionality (what we call an “epic”) gets its own deep dive. The starting point is usually previously epics or projects that incorporated similar features or functionality.

Who?

The Tech Lead (TL) typically oversees the tech evaluation process. Sometimes they’ll nominate a senior engineer who has experience with a similar problem or domain.

If we’re building something brand-new – for instance, a feature that doesn’t yet exist in any of our past projects – the nominated engineer is responsible for researching, benchmarking, and stress-testing potential technologies.

Here’s a quick analogy 💡

Imagine we’re chefs at a high-end kitchen. We’re planning a new dish. The TL acts like the head chef, assigning a sous-chef to source and test new ingredients. Not every exotic spice makes the cut, but if one dramatically improves the flavour? It goes on the menu.

How?

The evaluation process looks like this:

1. Research & Prototype: The nominated engineer investigates candidate technologies, possibly even building small proof-of-concept.
   
2. Technical Spec Document: Findings are written up in a detailed but digestible spec document.
   
3. Team Presentation: The engineer presents their findings in a demo with a Q&A session.
   
4. Cross-Team Interrogation: Everyone, from developers to product managers, gets to question the assumptions. Is it scalable? Secure? Aligned with the client’s revenue model? (We’ve had some lively debates here. 😃)
   
5. Validation: Once the team signs off, the new tech becomes part of that project’s stack for that epic.
   

And just like that, the stack evolves.

Yes, you’ll get to explore new tech

We won’t lie – most projects will start you off in our core stack, simply because it works and you’ll learn the fundamentals faster. But as you grow at CobbleWeb, there will be plenty of opportunities to:

• Research new tools
  
• Build proof-of-concepts
  
• Influence architectural decisions
  
• Take the lead on technical investigations
  

In fact, we want engineers who get curious. A junior engineer here once flagged an obscure performance bug in a feature – and then suggested a tweak using a different parameter. It worked. We adopted it. That engineer became one of our rising stars.

The bottom line: choose wisely, but stay curious

Technology evolves fast. But at CobbleWeb, we don’t chase trends – we evaluate purposefully. We build for outcomes, not just superficial performance. We favour pragmatic innovation over reckless reinvention.

To paraphrase Jeff Bezos: “We’re stubborn on vision. Flexible on details.”

So yes, you’ll have the chance to learn and test new tech, but always in service of something bigger: helping marketplace founders build the next big thing.

And who knows? The technology you evaluate next could be the foundation of our next success story.