Commitments

What we believe, and what we do about it.

Being a remote studio isn't a logistical footnote. It shapes who we can bring on, how we split the work, what we spend, and even what software we end up building. This page is about those consequences.

It's written under the same rule as our method: nothing we couldn't defend on a call. Where something is already practice, we describe it so it can be checked; where it's still an intention, we say so.

Remote work

Remote by nature. Engineering as the foundation. Product as the goal.

Plazoleta is a software engineering studio based in Madrid that works remotely. We design, build and evolve web and mobile applications, backend services and digital platforms for companies and startups, combining product thinking, current technology and engineering craft.

We aren't remote for lack of an office. We're remote because the discipline distributed work demands —writing decisions down, keeping the work reproducible, never depending on someone being in the room— is the same discipline software needs to survive in production. What makes a distributed team work turns out to be, almost point for point, what makes good engineering.

It also changes who we work with. Clients aren't buying presence, they're buying judgement; and we don't have to pick whoever lives forty minutes away, we pick whoever can do the work.

What that means in practice

Async by default: Decisions get written before they get discussed. A meeting that could have been a document costs everyone time at once; the document gets read when it's needed and is still there six months later, when someone asks why it was done this way.
Meetings with a reason: We meet to decide, to review work or to clear up a misunderstanding. Not to report progress: progress shows up as deployed software every two weeks.
Reproducible work: The project starts on a clean machine by following the repository docs. If you have to ask one specific person before you can begin, that person is a single point of failure — and a distributed team notices it sooner.
Written where people look: Decisions live in the repository and the project tracker, not in a private chat. The code and the infrastructure belong to the client from day one; so does the trail of why they look the way they do.
On site when it earns it: We travel when the meeting deserves it: a kickoff, a discovery workshop, a major handover. Remote doesn't mean never showing up; it means showing up is a decision rather than a routine.

Work–life balance

We measure the outcome, not the chair.

We work flexibly, on trust. Everyone organises their own day within the commitments the team has taken on: what's agreed is what ships in the next two weeks and when, not what time the laptop comes on.

Presenteeism doesn't measure work, it measures availability. And it measures it badly: the most valuable part of the job —understanding the problem, choosing well, cutting what isn't needed— doesn't come from staring at the screen for longer.

There's an honest catch, and it's worth stating: flexibility only works if things get written down and deadlines are told straight. The freedom to organise yourself comes from nobody having to chase anybody to find out where something stands.

How we keep it up

Outcomes, not hours: The commitment is to the agreed scope and the date, not to a time slot. If you need to start at seven or stop at five, you do.
A short shared window: A few overlapping hours a day for what genuinely has to be synchronous, and the rest of the day in long uninterrupted blocks. Engineering work is broken by interruptions, not by silence.
Outside that window, no reply is expected: Writing at eleven at night because that suited the sender doesn't create an obligation to answer at eleven at night.
No improvised on-call: If a project needs out-of-hours support, it's agreed in writing with the client, compensated and shared out. What we don't do is assume someone will just be there.
The plan moves before people break: When an estimate falls short, the first thing to move is scope or date, and we say so. Chronic crunch is a planning problem; paying for it with nights and weekends only hides it until the next time.

Diversity, equity and inclusion

A team that looks too much alike builds products that only work for people who look like them.

We believe in diverse, respectful teams and equal opportunity: everyone should be able to bring their experience and their perspective regardless of background, gender, age, orientation, beliefs, disability or personal circumstances. We value talent, collaboration and respect — and that's the easy part to write.

The part we find more honest is that the argument isn't only an ethical one. A homogeneous team shares the same blind spots, and the blind spots of the people building software end up inside the product: forms that only accept one shape of name, validation that assumes one shape of address, interfaces that only work if you see well, connect fast and move quickly.

We're a small studio, so diversity here isn't set by quota: it plays out in each hire, and because there are few of them, each one weighs a lot. What is within our control is the process, so the decision rests on what someone can do rather than on how familiar they feel.

What we do, and what we don't

Job ads about the work, not the archetype: We write what needs doing and what's actually required. Inflated requirement lists don't filter for capability, they filter for confidence: they mostly rule out people who don't assume they'll be picked.
Criteria set before we meet anyone: What counts and how it's weighted is decided before the first application arrives. Setting criteria afterwards is the most common way to retrofit a justification onto a decision made on affinity.
We assess the work: Bounded exercises close to what we actually do, with the same brief for everyone. No multi-day unpaid tests: those don't measure talent, they measure who can afford to give away a weekend.
Remote widens the map: We don't filter by postcode or ask anyone to move to Madrid. People with caring responsibilities, people far from a capital, people who can't get to an office — all still eligible.
Accessibility inwards too: We adapt tools and processes when someone needs them different. We treat product accessibility as a requirement from the first commit; it would be odd not to apply it to ourselves.
Zero tolerance for harassment and discrimination: Inside the team and in client relationships alike. A client who mistreats someone on the team is a client we stop having, and that conversation is ours to have, not the affected person's.

Sustainability

What doesn't get built is what consumes least.

Working remotely removes most of the travel our activity would otherwise generate: the daily commute and much of the travel to client sites. It is by far the largest environmental effect a studio our size can have, and it takes no symbolic gesture to achieve.

As a digital company we run paperless —proposals, contracts, documentation and signatures are electronic— with collaborative tools and a deliberately modest use of resources. There's no office to heat and no fleet to maintain.

But the part we care most about is the part inside the product, because that's the part that multiplies: what we ship runs thousands of times a day on machines somebody has to power. A backend that makes half the queries, an app that doesn't wake the phone's radio every minute and a site that doesn't ship three megabytes of JavaScript use less energy on every single use — and they're also faster and cheaper to run. Almost always, the efficient choice and the sustainable one are the same technical decision.

Where it shows

Less travel: No daily office, no on-site presence by default. Trips happen when the meeting justifies them, not out of habit.
Paperless operations: Documents, proposals and signatures electronic from end to end.
Buy before you build: If an off-the-shelf tool solves the problem, we say so. The project that doesn't happen consumes nothing: no budget, no servers, nobody's time.
Efficiency as a requirement, not a last-minute patch: Consumption is decided in the architecture, not in a final optimisation week. Fewer requests, less data over the wire, less work on the device.
Infrastructure sized to the problem: Over-provisioning “just in case” is paid for in invoices and in energy every month, and it's almost never revised downwards.
Software that lasts: Maintainable, documented code extends the useful life of what's been built. A full rewrite every three years has an environmental cost too.
Longer hardware life: A product that runs well on a four-year-old mid-range phone delays its replacement. Manufacturing a phone pollutes far more than using one.

Social impact

Technology fixes nothing on its own. Technology people can actually use sometimes does.

We believe technology can help solve real problems, on one condition that gets forgotten a lot: that people can use it. An excellent service that loses half its users at step two isn't solving a problem, it's distributing it worse.

So we build accessible, useful, people-centred products: accessibility as a requirement from the first commit, interfaces you can understand without a manual, and systems that behave when the connection is bad or the device is old. Those are the real conditions of far more people than a meeting room on fibre tends to assume.

It also means saying no. We don't build dark patterns —subscriptions you can't cancel, rigged consent, fake urgency— however well they convert. Something lifting a metric doesn't make it a good idea: it makes it an idea that takes longer to come due.

The other half is publishing what we know. Our method, our design foundations and the blog are written to be useful without hiring us: what to ask whoever builds your software, when custom development isn't worth it, what actually breaks in a sync. A client who understands what they're buying negotiates better and hires better, even if they hire someone else.

What it comes down to

Accessibility from the first commit: WCAG 2.2 at level AA as a working target, not a last-minute audit. This site publishes its own statement, with what it meets and what it doesn't yet.
Works in real conditions: Bad connections, modest devices, people in a hurry with noise around them. That's where software only ever tested in an office falls over.
No dark patterns: We don't design interfaces so that someone makes a mistake in our favour. If a client asks for one, we argue it out before building it.
Only the data that's needed: Collecting less data is less risk for whoever hands it over and less liability for whoever stores it. On this site analytics only run if you accept them, and you can revoke that from the footer at any time.
Knowledge in the open: Method, foundations and blog, public and without a signup form. What we learn on one project gets written up so it helps on a project that isn't ours.
Innovation with a cool head: We use new technology —AI included— where it solves something, and we say so plainly. We don't put it where it changes nothing, and we don't use it as an excuse for not understanding the problem.

What can be checked today

A commitments page that doesn't separate what's already done from what's merely intended is worth nothing. Here's the separation.

Already practice

Remote, async work, with decisions written down in the project repository.
Paperless operations end to end, signatures included.
A public accessibility statement that lists the known limitations.
Selection criteria fixed in writing before the first application is read.
Method, design foundations and blog published openly, with no signup.

Still an intention

We have no registered equality plan and no measured carbon footprint. At our size neither is mandatory, and publishing a number we haven't measured would be exactly the gesture this page is trying to avoid. When the time comes, we'll measure it and publish it here.
The team is small and fairly similar to itself. That's a fact, not a goal: the criteria above exist precisely so the next hires don't perpetuate it.

Not going to happen

Bought badges and certifications to put a logo in the footer.
Round numbers with no methodology behind them.
Offsetting on paper what hasn't been reduced in practice.

Last reviewed: 20 August 2026.

The way to check this is to ask.

If anything on this page reads like empty words, that's a good first question for the call. And if you want the other half, our method is written down just as plainly.

Tell us about your project Read the method