Application development for startups, scale-ups and enterprises
Most software projects do not fail at the end. They fail in week one, quietly.
We build your first application from scratch, a new product for your scale-up, or a section of your enterprise software. Full stack, one senior team, working software every two weeks, from the first sketch to production and a clean handover.
What the numbers say about software projects
Whether you are a founder with an idea, a scale-up adding its second product or an enterprise adding a module, the gap between projects that land and projects that drag is the same. It is not talent or budget. It is practice, and practice shows in the first two weeks.
-
45%
over budget, on average, for large IT projects, while delivering 56% less value than predicted.
McKinsey and University of Oxford, Delivering large-scale IT projects
-
973×
more frequent deployments for elite engineering teams compared with low performers, with a three times lower change failure rate.
DORA, Accelerate State of DevOps 2021
-
6,570×
faster lead time from commit to production for those same teams. Not because they work harder: because they release small changes through automated pipelines.
DORA, Accelerate State of DevOps 2021
Those gaps come from habits a project either has from day one or never gets: automated tests, deployment through a pipeline, small releases, and a demo every two weeks. That is as true for a two-person startup as for a bank. A supplier who plans the first demo for month three has already told you which side of the numbers your project will be on.
Many of the choices Roberto made when he joined still contribute today to the stability and quality of the project.
Peter Nieuwenhuyse Software architect & Angular coach Ten signs your next project will cost more than the quote
Run any proposal on your desk through this list, including ours. It works for a first app as well as for an enterprise module. Tick every statement that is true.
What separates the projects that land from the ones that drag
We have built applications for utilities, healthcare, industry and government, and first versions for companies that had nothing yet. The ones that went well shared five habits, and none of them are secret.
-
A first version is a question, not a product.
The most expensive mistake a founder can make is to build the whole idea before anyone has used part of it. The first version exists to find out whether real users do the one thing you believe they will do. Everything that does not serve that question waits. Version one should be in users' hands in weeks, not quarters.
Do this today. Write down the one thing a user must be able to do in version one, in a single sentence. Anything not needed for that sentence goes on a list for later, and stays there until the first users have spoken.
-
Integrations are the project.
Screens are the easy part. The payment provider, the identity provider with the group mapping nobody owns, the ERP with the undocumented API: these decide the timeline. Every overrun we have seen up close was an integration that was one line in the plan.
Do this today. List every outside system the application touches and who owns the credentials for each, before signing anything. If a name is missing, that integration is your first risk.
-
Working software every two weeks is your only early warning.
Status reports are green until they are red. A clickable increment cannot lie: either you can walk through the flow or you cannot. Two-week demos also move decisions earlier, which is where they are cheap.
Do this today. Ask for a clickable demo in week three of any project. A supplier who cannot deliver one has told you how the rest will go.
-
Handover starts on day one.
Code in your repositories, pipelines in your CI, infrastructure in your cloud account, from the first sprint. That holds for a startup without a single developer yet: the accounts are yours, we work inside them. The alternative is lock-in disguised as convenience, and it shows up at exactly the moment you want to change something.
Do this today. Ask three questions: whose repository, whose pipeline, whose cloud account? All three answers should be you.
-
Senior hands are cheaper.
A small senior team writes less code, takes fewer wrong turns, needs fewer meetings and leaves less to maintain. The day rate on a proposal is not the cost of the project; the cost is everything up to production plus the years after it.
Do this today. Compare proposals on the total cost to production plus twelve months of maintenance, not on the day rate. The cheapest rate rarely wins that comparison.
Roberto’s knowledge of Angular is exceptionally deep. It’s clear in everything he does that he understands exactly what is happening and why.
Ferdi Havenaar Manager IT Web & App, Vattenfall How a project runs
Fixed steps, short feedback loops, no long silences. The same structure whether we build a first version, a new product or a module in an existing suite.
What you can count on
- A scoped plan and a realistic estimate before you commit to the build
- Code, documentation and infrastructure in your repositories and accounts from day one
- Automated tests and deployment through a pipeline from the first sprint
- Working software you can click through every two weeks
- Your coding guidelines, security and compliance requirements, and release process, followed; or set up with you if you have none yet
- The people you talk to are the people who build; no handoff to a junior team
Roberto from Heckers Software joined our team. Not by immediately bulldozing through the code, but by carefully and thoughtfully paving the right paths with insight and calm.
Peter Nieuwenhuyse Software architect & Angular coach No obligation. A short call to see whether we are the right fit.
Three ways to work with us
Pick by how much of the work you want to keep in-house, and how much of it exists yet.
-
Minimum
The least you should do when a deadline depends on one overloaded team, or when you need a senior engineer before you can hire one.
One senior engineer, from three months
Monthly rate quoted per engagement
A senior full-stack engineer inside your team, accountable for a defined outcome, not just for hours.
- One senior Angular and .NET or Node engineer, part-time or full-time
- A defined outcome agreed at the start
- Works in your repositories, pipelines and rituals
- Architecture input in your refinements and reviews
- A delivery team and a project lead
- Fixed scope and fixed price
-
Standard
Most teams choose this
For the first version of a new product, or a module, portal or integration your own team has no room to build.
Fixed scope, two-week increments
On quote a fixed price for the build, set after discovery
A scoped application or section, delivered by our team in your codebase, with working software to click through every two weeks.
- Everything in Minimum
- Discovery, scoped plan and estimate before you commit
- Front end, API and data, built to your standards or set up from scratch
- Automated tests and deployment through a pipeline from sprint one
- A demo every two weeks, reviewed with your stakeholders or first users
- Documentation and a handover session with your developers
-
Advanced
For a complete application from first sketch to production: the platform your startup runs on, or a new product in your suite.
From discovery to go-live, and beyond
On quote scoped and priced after discovery
Architecture, front end, backend, deployment and handover by one accountable team, with the option to keep building it together.
- Everything in Standard
- Architecture designed for where you are going, not just for version one
- Integrations with payments, identity, ERP, CRM and whatever else you run
- Infrastructure as code in your own cloud account
- Go-live support and a first quarter of maintenance
- Optional: we keep building and running it with you
Every project is quoted on its own. Discovery is short and priced separately, and ends in a scoped plan and an estimate, so you commit to the build knowing scope and price. Our default stack is Angular, TypeScript, .NET, Node.js, SQL and Azure; where your platform requires another, we work in yours.
From the people we have worked with
Every engagement is led by founder Roberto Heckers. These are the words of people who worked with him.
-
Roberto delivers quickly, makes well-considered decisions, and actively contributes to architectural discussions. I can strongly recommend him as a full-stack developer.
Ferdi Havenaar Manager IT Web & App, Vattenfall -
Over several years at Marel, Roberto developed a big front-end Angular data visualisation framework for us, going from the earliest versions of Angular to the most recent.
Marc Caessens Senior Software Program Manager, Marel -
It was a pleasure working with Heckers Software and having Roberto on our team.
Nico Vandenbroucke IT-Directeur, Wit-Gele Kruis West-Vlaanderen
Questions we hear before every project
We are a startup with an idea and no developers yet. Is that too early?
No. That is the moment where the most money is saved or wasted. Discovery cuts the idea down to a first version real users can try, and we set up the repositories, pipeline and cloud account in your name from day one, so whoever you hire later walks into a working project instead of a supplier's black box.
Fixed price or time and materials?
Fixed price for a fixed scope, after discovery. Discovery itself is short and priced separately, and ends in a scoped plan and an estimate, so you never pay for a build you have not scoped. For the Minimum tier, an embedded engineer, it is a monthly rate with an agreed outcome.
Who owns the code?
You do, from the first commit. Everything lives in your repositories, your pipelines and your cloud account. If we part ways tomorrow, you lose nothing but us.
How does this fit with our security and compliance teams?
We involve them in discovery, not at sign-off. Your guidelines, review process and release gates apply to us as they apply to your own developers. We have worked under the requirements of utilities, healthcare and government. If you have no such requirements yet, we set up the sensible defaults so you are not the company that adds security after the breach.
What happens after go-live?
Your developers get a handover session, not just documentation. After that you choose: run it yourself, keep us on call, or keep building with us. There is no maintenance contract you did not plan for.
How big is the team?
Small and senior: usually two to four people, including the person you talked to first. That is enough for most applications, and it keeps communication direct.
Can you work inside our existing Nx workspace?
That is the most common case for enterprise clients. We build inside your workspace, respect its module boundaries and, where they are missing, help put them in.
Also from Heckers Software
- Architecture assessment Industry leading experts read your Angular or Nx codebase and hand you a ranked report and a roadmap. Fixed scope, two to three weeks for a full review. Read more
- Angular and Nx workshops Hands-on training on your own codebase: enterprise Angular patterns, Nx monorepos, AI-assisted development and UI libraries. Read more
Tell us about your project
An audit, a workshop, a new application or a codebase that needs rescuing. Describe where you are and we will tell you honestly whether we can help.
Prefer email? Write to roberto@heckerssoftware.com
It was a pleasure working with Heckers Software and having Roberto on our team.
Nico Vandenbroucke IT-Directeur, Wit-Gele Kruis West-Vlaanderen