Search

Software Engineer

PublishedPublished: 6/14/2022
Technology

Job Description

Software Engineer | Meridian Review Group

\n

Remote, London, Prague or Costa Rica | Full-Time or Long-Term Contract | $9,000–$12,000 per month depending on experience

\n

Meridian Review Group is looking for a Software Engineer to join our growing international team and help build the technology behind a rapidly expanding network of independent business, markets and economic publications.

\n

This is a role for someone who wants to build, not simply maintain.

\n

Meridian currently operates specialist publications covering major economies, financial markets, companies, technology, investment and economic change. Our network includes Global Markets Review, British Business Review, American Commerce Review, German Business Review, Dutch Business Review, Czech Business Review and Gulf Business Review.

\n

We are building Meridian as much more than a collection of conventional news websites.

\n

Alongside journalism, we are developing market-data products, company and executive databases, rankings, economic datasets, research tools, structured entity systems, internal editorial technology and new ways for readers to understand companies, industries, markets and economies.

\n

The role can be fully remote or based from one of our locations in London, Prague or Costa Rica.

\n

What We’re Building

\n

Meridian Review Group is an international publishing, research and intelligence group covering business, markets, investment, technology, AI, energy, infrastructure, manufacturing, finance and economic policy.

\n

Our model combines timely journalism with information designed to remain useful long after publication.

\n

That includes:

\n

    \n
  • Company and executive profiles
  • \n

  • Market and stock data
  • \n

  • Economic and regional guides
  • \n

  • Industry directories
  • \n

  • Rankings and indexes
  • \n

  • Investment trackers
  • \n

  • Original research datasets
  • \n

  • Company, sector and geographic databases
  • \n

  • Searchable reference products
  • \n

  • Specialist newsletters and recurring editorial products
  • \n

  • Data-backed journalism
  • \n

  • Research and intelligence products for professional audiences
  • \n

\n

The network is already reaching a meaningful audience, but we are building the infrastructure with a much larger goal in mind.

\n

Our ambition is to create a publishing and information platform capable of reaching millions of readers every month, ultimately building toward 10 million monthly visitors across the Meridian network. We currently reach approximately 480,000 readers across our publications in under a year and are growing rapidly.

\n

That creates a very different engineering challenge from building a single publication.

\n

We need systems that can support multiple brands, thousands and eventually hundreds of thousands of content and entity pages, rapidly growing search traffic, structured datasets, financial information, new publications and entirely new research products without the platform becoming increasingly difficult to maintain.

\n

We want to build systems that work well today while being designed for what Meridian could become several years from now.

\n

One Platform, Multiple Publications

\n

One of the more interesting parts of the engineering challenge is that Meridian is not one website.

\n

Much of the network operates from a shared technical foundation, while each publication maintains its own identity, editorial focus, domain, information architecture and audience.

\n

An improvement to the underlying platform might therefore benefit:

\n

    \n
  • Global Markets Review
  • \n

  • British Business Review
  • \n

  • American Commerce Review
  • \n

  • German Business Review
  • \n

  • Dutch Business Review
  • \n

  • Czech Business Review
  • \n

  • Gulf Business Review
  • \n

\n

and future Meridian publications that have not yet launched.

\n

This creates opportunities to build reusable systems for:

\n

    \n
  • Publishing
  • \n

  • Structured data
  • \n

  • Company profiles
  • \n

  • Authors
  • \n

  • Topics
  • \n

  • Geographic hubs
  • \n

  • Market data
  • \n

  • Rankings
  • \n

  • Research products
  • \n

  • Internal linking
  • \n

  • Search
  • \n

  • SEO
  • \n

  • Analytics
  • \n

  • Advertising
  • \n

  • Subscriptions
  • \n

  • Editorial workflows
  • \n

\n

while still allowing each publication to evolve independently.

\n

What You’d Work On

\n

There isn’t a narrow list of tickets waiting for you.

\n

You’ll work with our existing engineering, editorial and leadership teams to determine what we should build next and how we should build it.

\n

Depending on your strengths, that could include:

\n

    \n
  • Building new reader-facing products and features
  • \n

  • Improving the shared Meridian publishing platform
  • \n

  • Building infrastructure that allows us to launch new publications efficiently
  • \n

  • Creating tools for journalists, editors and researchers
  • \n

  • Building structured company, executive, industry and economic databases
  • \n

  • Developing market-data infrastructure
  • \n

  • Creating stock and company information products
  • \n

  • Building APIs and data pipelines
  • \n

  • Integrating external financial and economic datasets
  • \n

  • Building ranking and index products
  • \n

  • Developing systems for original Meridian research
  • \n

  • Improving article discovery and recommendation
  • \n

  • Building stronger topic, company, sector and geographic architecture
  • \n

  • Developing search and research functionality
  • \n

  • Improving technical SEO and Core Web Vitals
  • \n

  • Building entity-based internal linking systems
  • \n

  • Developing automated publishing and editorial workflows
  • \n

  • Creating internal monitoring and intelligence tools
  • \n

  • Building systems to monitor data freshness and accuracy
  • \n

  • Automating indexing, canonical, redirect and orphan-page audits
  • \n

  • Improving analytics and understanding how readers interact with the network
  • \n

  • Experimenting with AI-assisted research, classification and editorial tooling
  • \n

  • Building future subscription and premium research products
  • \n

  • Developing infrastructure for advertisers and commercial products
  • \n

\n

Some projects will be highly visible.

\n

Others might remove hours of repetitive editorial work or quietly improve thousands of pages across the network.

\n

Both matter.

\n

Building for Scale

\n

A major part of this role is helping us prepare Meridian for a much larger audience.

\n

We want the network to be technically capable of supporting 10 million monthly visitors as the publications grow.

\n

This is not simply a traffic problem.

\n

Growth means considerably more:

\n

    \n
  • Articles
  • \n

  • Companies
  • \n

  • Executives
  • \n

  • Stock pages
  • \n

  • Geographic pages
  • \n

  • Industry pages
  • \n

  • Rankings
  • \n

  • Datasets
  • \n

  • Publications
  • \n

  • APIs
  • \n

  • Internal relationships between entities
  • \n

  • Search-engine crawling
  • \n

  • Data updates
  • \n

  • Editorial activity
  • \n

\n

That means thinking seriously about:

\n

    \n
  • Performance under significantly higher traffic
  • \n

  • Efficient rendering and caching
  • \n

  • Database and API performance
  • \n

  • Infrastructure reliability
  • \n

  • Search and indexing at very large content volumes
  • \n

  • Programmatic page generation
  • \n

  • Cost-efficient scaling
  • \n

  • Monitoring and observability
  • \n

  • Content delivery architecture
  • \n

  • Data freshness
  • \n

  • Search-engine crawl efficiency
  • \n

  • Resilience during major market or breaking-news traffic spikes
  • \n

  • Shared infrastructure across multiple domains
  • \n

  • Preventing architectural decisions that work for seven publications but become problematic at twenty
  • \n

\n

We do not expect every engineer to arrive having built a 10-million-user publishing platform.

\n

We do want people who understand the difference between building something that works and building something that can continue working as usage, data and complexity increase dramatically.

\n

Data Is Becoming a Major Part of Meridian

\n

Meridian is increasingly building products where journalism and structured information sit alongside one another.

\n

Global Markets Review, for example, incorporates company and market information.

\n

Across the wider network we are developing products including company databases, executive profiles, economic datasets, investment trackers, rankings and proprietary research.

\n

Examples include research and data projects around:

\n

    \n
  • AI adoption
  • \n

  • Corporate leadership
  • \n

  • Gulf AI and infrastructure investment
  • \n

  • Companies and markets
  • \n

  • Regional economies
  • \n

  • Technology ecosystems
  • \n

  • Investment
  • \n

  • Energy and infrastructure
  • \n

\n

We expect this side of Meridian to expand considerably.

\n

Some products may begin as datasets used by journalists.

\n

Others may become searchable public resources.

\n

Some may eventually become subscription or professional intelligence products.

\n

Engineering will play a major role in determining how those systems are designed.

\n

Building an Entity-Based Publishing Platform

\n

One particularly important engineering direction for Meridian is structured information.

\n

An article about a company should not exist in isolation.

\n

That company might also connect to:

\n

    \n
  • Its company profile
  • \n

  • Executives
  • \n

  • Stock information
  • \n

  • Headquarters
  • \n

  • Countries and cities
  • \n

  • Industries
  • \n

  • Competitors
  • \n

  • Rankings
  • \n

  • Investment activity
  • \n

  • Previous Meridian coverage
  • \n

  • Relevant economic indicators
  • \n

  • Research datasets
  • \n

\n

The same applies to people, industries, regions and markets.

\n

Over time we want Meridian to become increasingly good at understanding and representing those relationships.

\n

That creates interesting engineering problems around databases, entity resolution, structured data, search, internal linking, page generation and information architecture.

\n

The Kind of Engineer We’re Looking For

\n

We’re less interested in finding somebody who matches a rigid technology checklist than somebody who can look at a problem, understand why it matters and work out a sensible way to solve it.

\n

You’ll probably enjoy this role if you like a relatively high level of ownership.

\n

We’re particularly interested in engineers who:

\n

    \n
  • Have built real production software used by real users
  • \n

  • Are comfortable moving between frontend and backend problems
  • \n

  • Can understand an unfamiliar codebase quickly
  • \n

  • Care about performance, reliability and maintainability
  • \n

  • Think about scale rather than only immediate implementation
  • \n

  • Understand databases and structured information
  • \n

  • Enjoy solving ambiguous problems rather than only executing predefined tickets
  • \n

  • Can explain technical trade-offs to non-engineers
  • \n

  • Are interested in publishing, markets, research, data or information products
  • \n

  • Understand that SEO can be an engineering problem as much as a marketing problem
  • \n

  • Know when a simple solution is better than an elaborate one
  • \n

  • Are comfortable working asynchronously with an internationally distributed team
  • \n

  • Like experimenting, but can distinguish useful experimentation from unnecessary complexity
  • \n

  • Are interested in building systems that may eventually serve millions of users
  • \n

\n

You do not need previous experience working for a newspaper or media organisation.

\n

Experience building SaaS products, research platforms, financial products, data products, marketplaces, content systems or startup products could all translate particularly well.

\n

Technology

\n

Our current environment includes technologies and tools such as:

\n

    \n
  • TypeScript
  • \n

  • JavaScript
  • \n

  • React
  • \n

  • Next.js
  • \n

  • Node.js
  • \n

  • Git and GitHub
  • \n

  • Vercel
  • \n

  • SQL and modern databases
  • \n

  • REST APIs
  • \n

  • Structured data
  • \n

  • Analytics infrastructure
  • \n

  • Modern web performance tooling
  • \n

  • Technical SEO systems
  • \n

  • AI APIs and automation workflows
  • \n

  • External financial, market and economic datasets
  • \n

\n

Experience across the entire stack is not expected.

\n

Strong engineering fundamentals, curiosity and the ability to learn quickly matter considerably more than having every technology on your CV.

\n

Engineering Inside a Publishing and Research Group

\n

One of the things that makes this role different is the proximity between engineering and the rest of Meridian.

\n

You won’t be several layers removed from the people using what you build.

\n

An editor might identify a research process that takes several hours and could be automated.

\n

A financial dataset might need to update thousands of company pages.

\n

A new ranking might require its own methodology, database and publishing architecture.

\n

A new Meridian publication might need country, company, topic and city infrastructure before launch.

\n

Search data might reveal an entirely new information product worth building.

\n

An internal dataset might become valuable enough to turn into a public research platform.

\n

We want engineering involved in those conversations early.

\n

The best solution may be a new application.

\n

Sometimes it might be an API, an automation, a database, an interface or twenty lines of code that eliminate an unnecessary workflow.

\n

A Small Team With Real Ownership

\n

Meridian remains small enough that individual engineers can have a substantial effect on the product.

\n

You won’t be engineer number 400 responsible for maintaining one subsection of one product.

\n

You’ll be able to influence architecture, propose products, question existing systems and take ownership of meaningful parts of Meridian’s technical roadmap.

\n

That might mean owning a research product.

\n

It might mean redesigning part of the publishing architecture.

\n

It might mean developing Meridian's market-data infrastructure.

\n

It might mean building the system that allows us to launch the next ten publications.

\n

We want people who see things that should exist and are comfortable helping us build them.

\n

Location and Working Structure

\n

The position can be:

\n

    \n
  • Fully remote
  • \n

  • Based from London
  • \n

  • Based from Prague
  • \n

  • Based from Costa R
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...