Working at Progymédia

Understanding the client is part of everyone’s job

Our clients know their products, their trade and their operations. They do not necessarily know every technology issue a project involves. Our role is to understand their reality and help them make appropriate decisions.

At the start of a project, we introduce the client to the whole team: the company, its size, products and ways of working, the problem to solve and the objectives to meet. We also clarify what success will look like.

That context belongs to everyone contributing to the solution. Knowing your task helps you check whether your code works. Understanding the objectives also helps you judge whether your work adds value.

We take responsibility for delivering reliable, secure and suitable solutions within agreed budgets and timelines. The quality of the result is a shared responsibility.

A day with the team

The day generally starts at a MacBook Pro. Each person reviews their responsibilities and current priorities, then organizes their work with autonomy.

We use Tropy, our own work management platform, to follow projects, tasks, support requests and decisions. It also supports communication with clients: requests are documented and their progress remains visible.

Our days are not structured around a succession of mandatory meetings. Conversations happen as needed: discussing a hypothesis, consulting someone with relevant expertise or reviewing a project with its leads.

Our small team brings together complementary skills in backend, frontend, infrastructure and architecture. Several people contribute to the same projects. Collaboration matters, even in a quiet environment.

Developers communicate directly with clients, primarily through Tropy. Direct conversations, including huddles, help when speaking is more useful than a chain of messages. Project leads generally handle larger meetings; developers join when their expertise is relevant.

We want everyone to understand the context behind a request and feel able to ask the questions they need to ask.

Room to concentrate, with conversations that move work forward

We work in an open-plan office where we try to maintain an atmosphere closer to a library. People need space to concentrate and think without constant interruptions.

Colleagues talk, help each other and gather spontaneously when a subject calls for it. Quiet and collaboration can work together when both respect the need for focused work.

We invest in capable computers, quality chairs and adjustable desks. We prefer to direct resources toward good working conditions and compensation rather than entertainment facilities.

We do not have a ping-pong table. We encourage healthy habits, physical activity and health, and want people to have time for what matters outside the office.

Autonomy includes knowing when to ask for another perspective

We expect developers to use their judgement. A request deserves examination: are we solving the problem or adding a temporary patch to a situation we have not fully understood?

We sometimes use the image of yellow and red lights. When a problem first appears, we examine the situation and make a correction. If it returns, we need to stop and revisit the assumptions, architecture or system structure.

We want to avoid stacking patches on top of patches. Depending on experience, someone may start by recognizing a difficulty and raising it. Over time, they can propose solutions, explain their reasoning, build prototypes and take ownership of improvements.

Asking for help is part of autonomy. We first try to understand the support being sought: discussing assumptions, validating an approach, getting a different perspective or thinking together. The aim is to help the person progress rather than routinely taking over the problem.

Room for mistakes, with a responsibility to learn

We all make mistakes. At Progymédia, a mistake is an opportunity to understand what did not work. We do not seek to punish someone for getting something wrong.

We do expect people to acknowledge mistakes, communicate uncertainty and investigate the causes of a problem. When an error repeats, an immediate fix is no longer enough: what is missing from our checks, documentation, tests or system design?

That standard applies to our organization too. We have built our own tools to manage projects, communicate and automate operations. When those tools show their limits, we look for ways to improve them.

Project documentation, effort estimation and planning are among the areas where we want to keep progressing. Continuous improvement concerns our methods as much as our software.

AI is an everyday tool. Judgement remains our responsibility.

We use artificial intelligence extensively to explore solutions, produce code, accelerate research and automate tasks. That assistance does not transfer responsibility for the result to the tool.

People define the objectives, boundaries and checks for delegated work. We need to be able to understand AI’s proposals, challenge them and take control again.

Before delivery, we examine technical decisions, quality, security and maintainability. We also verify that the solution serves the client’s objectives. Working code may still need changes; an impressive solution may be disproportionate to the need.

Engineering fundamentals and an understanding of systems therefore remain essential. Our value lies in understanding, deciding and taking responsibility for the quality of what we build.

Understanding the technical environment from end to end

We develop and operate a substantial part of our own technology. Projects involve interfaces, backend services, APIs, databases, integrations, security and deployment. Understanding the connections between these areas helps us make better decisions.

Our environment evolves. These are its main reference points today; they describe the range of the work rather than a list of technologies someone must master before joining.

We also develop our own connectors and synchronization mechanisms to link different ERP and business systems with applications. The challenges vary with each client’s environment.

• Workstations and collaboration: MacBook Pro and macOS for most developers; Git, GitHub and AI-assisted development tools. Tropy supports project management and communication.
• Interfaces: TypeScript is our main development language. We use React, Next.js and Vite, with progressive web applications and offline capabilities where the need calls for them.
• Services: Node.js, TypeScript and Fastify for services and APIs; Temporal for process orchestration. We are introducing Rust for certain components and native agents. Go serves particular needs, and some legacy systems use Java.
• Data and search: MongoDB, PostgreSQL, Typesense, DuckDB for certain analytical needs, Payload CMS and object storage for files and resources.
• Operations: OVHcloud for a significant part of hosting; containers and Kubernetes, NGINX Ingress and cert-manager. GitHub Actions and Argo CD support continuous integration and deployment; Prometheus, Grafana and other tools support monitoring.
• Identity and access: Keycloak and OpenID Connect are part of our authentication and identity management environment.

We look for solid foundations, an understanding of the concepts and the ability to learn. We do not expect someone to be an expert in every area.

Developing expertise and passing knowledge on

A strong specialty can benefit from other perspectives. A backend developer gains by understanding the constraints of an interface, a database or a deployment. Understanding the client’s operations can also change how a feature is designed.

We encourage that breadth without asking everyone to become an expert in everything. Curiosity, research and shared knowledge are part of everyday work.

Teaching has always mattered to us. We have welcomed interns and recent graduates and supported their professional development. Some continued their careers elsewhere; others became long-standing members of the team.

We put that practice aside for several years. We would like to return to it as the company begins growing again. The aim is to pass on methods, quality habits and the ability to make sound decisions, along with languages and tools.

New team members bring their own ideas too. A good proposal can come from anyone. We need to listen, explain and evaluate it, even when it challenges an established habit.

A team, without an emotional obligation to the company

Progymédia is a family-owned business. As colleagues, we build a professional team: people who respect and support each other while working toward shared objectives.

Everyone keeps their own life, ambitions and freedom to choose a path. Leaving the team to pursue a career elsewhere is part of professional life. We want healthy relationships based on respect and trust, without an emotional obligation to the company.

We do not treat long hours as proof of commitment. We want people to be focused and effective at work, then have time for family, friends and their own activities.

Some technical operations need to happen outside regular hours to limit disruption to clients. We try to plan and organize them and keep their frequency down.

Our aim is to build a team that can do excellent work while maintaining a healthy balance.

What makes us proud

Our satisfaction comes from a project understood and delivered with care, a client getting a useful solution, and a reliable, maintainable application whose security has been taken seriously.

When a problem appears, we want a team that comes together to understand and resolve it. When a better approach is proposed, we want to be able to reconsider our decisions. And when a project succeeds, everyone should be able to recognize their contribution.

We are a small team with substantial responsibilities. We do not have every answer, and our methods continue to evolve. Our ambition is to do quality work, keep learning and build lasting solutions we can be proud of together.

That is what working at Progymédia means.