Twice a year, our Builders org hits pause on roadmap work for three days to explore what usually doesn't make it to the top of the backlog: experiments, moonshots, and new ideas for how we build.

Builders Playground runs remotely. People pitch ideas in advance and form small teams around them, and the event ends with a watch party where every team demos what they built. The guidelines are light: projects are self-contained and don't change how production behaves during the event. Some become features, some validate an idea for later, and some are just for fun.

This post covers the last two editions: March, when more than 20 teams chose from more than 40 ideas, and September, when 38 ideas were proposed and 28 became working projects, each shown in a three-minute demo at the watch party.

Real phones, real carriers

Testing telecom software means testing on real devices, and Gigs already had a test rig in its London office: a Raspberry Pi running STF, an open-source device farm, with Android phones attached over USB. Anyone at Gigs could control the phones from a browser, but each test was still done by hand.

During the March playground, one team put a REST API in front of the rig, with calls to list devices, place calls, send SMS and download files. They connected it to Glow, our in-house end-to-end testing tool. By the end of the third day, one automated test started an activation, placed a real call to a freshly provisioned number, and collected network analytics from a phone in another country.

The rig started as a hackathon project at our Gigs Republic offsite in Crete in October 2025, where a team built it from a Raspberry Pi and a bundle of USB cables and won Most Impactful Hack. After a trial in Berlin it moved to London, and more rigs now run in New York and Dublin.

Six months later, a team took on number porting, which is how a customer keeps their phone number when they switch carriers. Customers often mistype their porting details: a PIN with the wrong number of digits, or a phone number in the account number field. Today we find out when the carrier rejects the request. The team looked at historical porting data for these patterns and prototyped a precheck endpoint that warns about likely mistakes before the request goes out. The warnings are advisory, not blocking, because carriers change their formats over time, for example moving from four- to six-digit PINs.

Another team looked at a slower kind of telecom work: integrating a new carrier network. An integration takes months, involves expansion, product, connectivity and engineering teams, and comes with commitments to customers, providers and regulators. The team prototyped a visual map of an integration's state, with its milestones, blockers and open decisions, and used AI tooling to surface updates that belong on it.

Making the API easier to build on

Developers build on Gigs through its API, so the documentation matters as much as the endpoints. One team built a CLI that drafts and updates API documentation from inside the repository. It reads the OpenAPI schema, adds our internal style guide and a scoring rubric, and writes a draft. It then scores the draft on eight quality dimensions and revises it until it passes. One command produces a complete page: prerequisites, overview, usage, error handling and next steps. You can read the current docs at developers.gigs.com.

The latest playground brought two teams to the Dashboard, where developers check what their integration is doing. Understanding an event there often meant opening it and reading the raw JSON payload. One team worked on showing the key values directly, linking each event to the resources it touches, and stepping from one event to the next. That work is now on the roadmap.

The other team exposed request logs. We already record every API request, but developers couldn't see them, so debugging an integration often meant asking us. The prototype lists the requests made in a project or for a single resource, such as a subscription, so developers can trace what happened to that resource across requests themselves.

Finding the right logs

Anyone who has debugged across several services knows this one: "I saw it in the logs earlier. Now give me 20 minutes to find which logs."

One team built a proof of concept for OpenTelemetry, the vendor-neutral standard for metrics, traces and logs. The goal was one way of collecting telemetry across all services, without tying us to a vendor, and with longer retention for problems that only show up a day or two later. The team added middleware that records SQL queries and outgoing HTTP calls with few changes to existing code, and turned on continuous CPU and heap profiling for our Go services.

A smaller project from September went to production almost immediately. Every request at Gigs carries a correlation ID that ties together the logs it produces. One engineer stored that ID with each event and showed it on the Dashboard's events page, so support and engineers can go from an event to every log line of the request behind it.

Another team prototyped event replay: sending historical events from a topic to a chosen subscription again. It helps when recovering from an incident, or when filling a new database table from past events.

What happens after the demo

A demo isn't the end of a project. After September's playground, every project that produced something was triaged: what it would take to reach production, how much effort that is, and which team would own it.

Nine projects graduated onto the roadmap. Three of them were already in production when the results were announced, eleven days after the demos, and a redesigned internal admin tool followed about a week later. Graduating doesn't skip the usual process: a project that moves onto the roadmap goes through the same product, design and security reviews as any other work.

Projects that don't graduate still leave something behind. The team writes an architecture decision record (ADR) with the reason and what they learned. One team evaluated durable execution engines, for example. That evaluation is now an ADR, so the next person with the same question starts from it.

Why we keep doing it

Builders Playground gives three uninterrupted days to ideas that cut across teams: better tests, clearer docs, faster debugging. Much of it makes other work faster once it exists. The test rig is a good example: a hackathon box that became shared equipment in three offices, and then something our end-to-end tests can call.

At Gigs, we're turning global telecom infrastructure into software that any developer can build with and that operates itself. That means getting every layer right, from the APIs and the testing infrastructure to the observability tooling and the documentation.

If you want to join us in building telecom for the intelligence age, you can take the first step at gigs.com/careers.