TypeScript developers on a project basis instead of employment

Why this question is popping up in so many teams

The situation is often similar. A customer portal must be ready for the spring trade show, the new ERP interface is being built in parallel, and the three people on the team are booked until Christmas. So a headcount is requested. After all, you always need TypeScript, and hopefully once someone is in, they stay.

The catch is time. In the Bitkom Study 2025 On average, it took 7.7 months to fill an IT vacancy. Issue 2026 This shows the situation has hardly eased. 97 percent of companies with IT positions to fill struggle, and almost a third receive practically no applications. In Austria, according to Wirtschaftskammer Wien for 2025, around 28,000 IT specialists, 6,000 of them in Vienna alone.

If you factor in onboarding, the new hire will at best be productive after the trade show. So ask a different question: do you need someone long-term for this initiative, or reliable capacity for a few months who can contribute from week one?

What a full‑time hire costs beyond salary

When comparing, many focus only on gross salary. That's like looking at a car's list price and forgetting insurance, service, and fuel. A permanent hire includes items not listed in a job ad.

• Non-wage labor costs and, in Austria, special payments—i.e., 14 instead of 12 salaries per year.
• Recruiting with ads, hours of interviews, and often a commission for recruitment consultants
• Laptop, licenses, workspace, and training
• Vacation, public holidays, and sick leave during which nobody works on the backlog
• The onboarding until someone can safely modify an unfamiliar codebase—typically several weeks.

However, the largest item rarely shows up in any calculation: the months the position stays unfilled. If a new portal is supposed to bring in $20,000 in revenue per month or save costs in support, each month of delay costs that amount. The calculation is uncomfortable, but it needs to be on the table before you decide.

A project-based engagement costs more per hour than the converted salary of an employed person. In return you pay for work on your product, not for recruiting, idle time, or training. Pricing overview for dedicated developers.

What happens after the project

Hardly anyone asks the uncomfortable question when applying for the role: What will the new person do once the portal is live and the peak is over? If there’s enough work afterward, fine. If not, you either invent tasks or let them go—and both cost money and team morale.

Employment is also a legal commitment that goes beyond the project. In Germany, the probationary period is at most six months; after that, general dismissal protection applies in companies with more than ten employees. In Austria, the probationary period is even shorter, at one month. Afterwards, employers must observe notice periods of at least six weeks, increasing with years of service. What applies in each case depends on the employment contract and the applicable collective agreement, so check with your HR department if in doubt.

This isn't an argument against hiring. It's an argument for describing the need dispassionately. A project with a clear start and end rarely suits an open‑ended employment contract.

What project-based means in practice

Project-based does not mean someone picks up a spec and three months later returns a finished package. A good engagement looks almost like an in-house hire. The TypeScript developer works in your repository, joins your dailies and sprint reviews, opens pull requests, and gets code reviews from your team. The difference is in the contract, not the daily work.

There are two basic contractual forms. Under a Werkvertrag (contract for work), the provider owes a precisely described result for a fixed price. That sounds secure but only works if requirements are fully defined up front. With software that is rarely the case and every change becomes a renegotiation. Under a Dienstvertrag (service contract), you pay for qualified working time and control priorities yourself. For products that may change during development, the service contract is usually the more suitable arrangement.

At Typescriptaz, all developers are employed by Anexia Digital Engineering GmbH. You book a specific person either on the monthly plan with 150 hours or via an hour bundle starting at 80 hours, and the monthly plan can be canceled monthly. If you want to hire a TypeScript developer, this gives you project flexibility with an employer in the background who provides equipment, training, and security. The stacks we cover around TypeScript are on the page dedicated TypeScript developers.

Freelancer or service provider with employed developers

The obvious alternative to permanent employment is a freelancer. That can work very well, especially for clearly defined tasks. According to Freelancer Compass 2026 According to freelancermap, the median hourly rate in software and web development is 90 euros, and 95 euros across IT overall. That's a useful reference for any offer you receive.

You should clarify three points with freelancers in advance.

• Availability. Many work in parallel for multiple clients. Ask openly how many hours per week are reserved for you—and what happens if another project catches fire.
• Outages. If the person is sick or on vacation, the work stops. There is typically no replacement.
• False self-employment. If someone is permanently integrated in Germany like an employee, they can be deemed employed under social security law. Certainty comes from a status determination procedure at the Deutsche Rentenversicherung. The extent of the uncertainty is also shown by the Bitkom 2026 study, in which almost half of companies want a reform of that procedure.

A provider with employed developers won't solve every issue automatically, but it shifts responsibility. Your contracting partner is a company, the developers are employed there, and questions like vacation planning or replacement for long absences can be handled in the contract. Ask every vendor about this specifically, including us.

When you're better off hiring in-house

There are clear cases where permanent employment is the right answer, and we say that in conversations. If TypeScript is the core of your product and the roadmap is full for the coming years, that knowledge belongs permanently in‑house. The same applies when domain knowledge is your real advantage, for example in the tariff models of an insurer or the processes in a clinic.

Leadership roles should also be in‑house. Engineering management or technical product ownership cannot be delegated on a project basis without decisions leaving the company.

Often a combination makes the most sense. A project-based TypeScript developer bridges the months until hiring, keeps the initiative on schedule, and onboards the new colleague afterward. That way you don't lose time and still build for the long term.

How to prepare a project-based engagement

Whether a deployment succeeds is often decided before the first day of work. These six points have proven effective.

1. A one‑sentence goal. What must work in the end, and how will you know? “Merchants can create and cancel orders in the portal themselves” is a goal. “Improve the portal” is not.
2. Set up access in advance. Repository, ticketing system, staging, and chat should work on day one. Every day without access is paid waiting time.
3. A subject‑matter contact. Someone from your team answers domain questions and makes decisions when something is unclear. If that person is absent, guesses are made—and guessing is expensive.
4. A Definition of Done. When is a ticket done? Tests, review, documentation, deployed to staging? Agree once and stick to it.
5. Handover from day one. Decisions are recorded continuously, not only in the last week. Short architecture notes in the repository are sufficient.
6. One fixed appointment per month. There, they monitor progress, hours, and priorities and decide whether the scope should remain as is.