Software needs someone to take responsibility for it
AL+ takes over existing software, stabilizes it, modernizes it, and maintains it for the long term. We also turn prototypes and AI-generated applications into production software, and we build and run our own product, PostDeploy. We are an independent multidisciplinary software company in Timișoara, Romania, working remotely with clients wherever they are.
What we do with existing software
-
Software takeover
We take over software built by another developer, agency, internal team, or AI workflow and become its technical owner.
When the people who built it are gone, unreachable, or no longer trusted.
-
Software maintenance
We keep web applications, SaaS products, and internal systems dependable: releases, fixes, dependencies, infrastructure, security updates, and ongoing development.
When software is in production and needs someone responsible for it every month, not only when it breaks.
-
Software modernization
We modernize legacy applications in place: stabilize first, then replace the parts that block change, without a risky full rewrite.
When the system works but has become slow, fragile, expensive, or impossible to change safely.
-
Productionizing AI-generated software
We turn prototypes, MVPs, and AI-generated (vibe-coded) applications into production software that someone understands and answers for.
When an application built quickly, often with AI tools, works for a demo but not for real users.
These are one responsibility seen from four situations, not four tiers. Most engagements start with a takeover or a review and settle into maintenance. Modernization happens inside maintenance, one bounded change at a time.
We are most useful when software already exists: it was inherited, it lost its original developer, it was built quickly or largely with AI, or it works but has become difficult to change. We are not a staff-augmentation vendor, an emergency rescue line, or a security firm; we are the team that owns your system.
Software problems are rarely only software problems.
Software exists inside human systems. It is used by people under time pressure, maintained by teams with their own constraints, and paid for by organizations with their own politics.
AL+ combines experience across software engineering, product design, product thinking, psychiatry, and psychology. It was founded by Paul Bădărău, the technical co-founder, and Loredana Gavrilovici, a pediatric psychiatrist. Clinical training does not make anyone a better engineer. It does change what we notice.
-
Paul Bădărău
- Loredana Gavrilovici
-
What that changes in practice
We read requirements as statements about people, not only about features. We design for attention that is limited and interrupted. We treat accessibility as a normal part of the work. We notice when a technical problem is actually an organizational one, and we say so.
-
What it does not mean
We make no medical claims about software. We do not sell "psychologically optimized" products. The value is ordinary: clearer workflows, fewer surprises for users, and requirements that survive contact with reality.
How we think about software
-
Software needs an owner.
One named party should know how a system works and answer for it. When that role is empty, every change gets slower and every estimate gets wider. Read “Software needs an owner”.
-
Simple systems age better.
Fewer moving parts means fewer things that break at three in the morning. We remove complexity before we add capacity.
-
Rewrites are conclusions.
We decide between repairing and replacing a system only after reviewing what it does in production and where its risk sits. Read “Repair or rewrite?”.
-
Maintenance is product work.
The years after launch are where a product is kept correct, kept changeable, and made better. We staff and plan them as product work. Read “Maintenance is product work”.
-
AI changes how code is produced. It does not remove technical responsibility.
Generated code still has to be deployed, secured, backed up, and understood by someone. We keep what works and add what is missing. Read “AI-built software still needs an engineer”.
-
Understand the system before changing it.
Access first, then production, then the knowledge nobody wrote down. Feature work starts once one safe change has shipped end to end. Read “Taking over software after the developer leaves”.
PostDeploy: everything after you ship, in one place.
PostDeploy is our own product, built for the part of software we care most about: the years after launch. Uptime and API monitors, heartbeats for scheduled jobs, cookieless analytics, error tracking, a public status page, and a changelog, all in one project.
-
Monitor
Checks your site and API on a schedule. Heartbeats treat a missing ping from a scheduled job as a failure, so silence does not wait for a customer email.
-
Measure
Analytics without tracking cookies, persistent visitor identifiers, or stored IP addresses. Daily identifiers rotate, so visits cannot be linked across days.
-
Observe
Reported errors sit in the same project as the monitors and analytics, so an incident is read in one place.
-
Publish
A public status page for when something changes, and a changelog for releases, kept beside the project.
One flat price per organization, with no per-seat fees or usage overages. Alerts go to email, Slack, Discord, Telegram, or a webhook. A coding agent can set up monitors, heartbeats, and status pages over MCP.
Try PostDeploy free for 14 days Read why we treat maintenance as product work
Thoughts
Things we have learned by building, inheriting, repairing, and maintaining software. Checklists and arguments you can use without hiring us.
-
A control nobody has watched fail is not a control
Lessons from a signup-abuse incident on a platform we took over: the previous developer's abuse controls existed in code, passed review, and did nothing. What made them inert, how we fixed them, and the practices we kept.
-
Codebase takeover checklist: what to inspect before accepting a system
A reusable checklist for taking over software from another developer, agency, or team: access, production, data, change safety, dependencies, security, knowledge, and cost. Use it before you agree to own the system.
-
Production-readiness checklist for AI-generated applications
Thirty concrete checks that separate a working AI-generated (vibe-coded) prototype from production software: security, data, failure handling, operations, coherence, dependencies, and ownership.
-
What a good software handover should contain
The seven artifacts an outgoing developer or agency should hand over with a software system: access, environment map, operating manual, architecture notes, decision log, open issues, and a recorded walkthrough.
-
Software needs an owner
Software becomes expensive when nobody clearly owns it. Ownership is a role, not a repository permission, and most struggling systems are missing it.
Have software that needs an owner?
Write a few sentences about the system, who built it, and what worries you. You will hear back from the people who would do the work, not from a sales process. We reply in English or Romanian.