iwebforyou builds SaaS products and internal business platforms with accounts, roles, workflows, dashboards and connections to other systems. We work in five stages. The requirements are written first, then the code.
If your business runs on spreadsheets, email and manual approvals, or if you want to sell a software product of your own, this page is for you. Here you see exactly what we build, what you gain when the specification is written before the first piece of code and how quality is checked up to handover. The simple idea behind it all: software built with a system lasts over time.
We build software that supports how your business really works. In practice:
User accounts and login, so everyone sees only what belongs to them.
Roles and permissions, so a manager, an operator or a customer can each do different things.
Workflows: the steps a task goes through, for example request, check, approval, record.
Dashboards: one screen with the numbers that matter, available whenever you need them.
Connections to other systems, such as your accounting software, your email or a payment service.
Projects are usually of two kinds. The first is a SaaS product that you sell to your own customers. The second is an internal platform that replaces the many spreadsheets and emails inside your business. In both cases we first define what the system must do, and only then how it will do it.
Every platform starts from written requirements that you approve. That way the system is built on decisions, not on guesses, and you avoid the cost of doing it twice. You get software designed for daily use, not for an impressive demo.
If you need a website that presents your business, the right service is business websites. This way every project gets the attention it deserves.
Every platform goes through the same five stages as our websites, as described on the process page. On platforms the stages focus on the software: requirements, system design, controlled build and tests.
Analysis and requirements. We define what the system must do, for whom and with which limits. You approve a written project scope.
Structure and simple screen layouts. The first part of the system design: how the data, the roles and the screens connect, with simple layouts without colors.
Design rules. Every screen looks and works the same way. This makes future changes cost less.
Build and quality check. The system is built feature by feature, with a check before the next one. At the end it is tested on real scenarios from your daily work.
Handover. Your platform is online. You get what you need to run it yourself or with your team.
The technology is chosen from the requirements of your project. That is why the proposal is made for each project separately. What matters is that the system is designed well, lasts over time and can be maintained by your team or ours.
Checking is part of the build from day one. Our own tool, the Planner, builds an application from written specifications without supervision. For every feature the test is written first and then the code. Then we check the result in a real browser and compare it with the approved design. Each step moves on only when all checks pass. See how it works in the Planner case.
In addition, a team of agents examines the finished project for bugs, usability problems or security weaknesses. Every confirmed finding is fixed with a test that fails before the fix and passes after it. This way every mistake becomes a permanent test. More in the quality and security agents case. We tell you openly what is checked and how.
It is for businesses that want to move a real process into software, with one clear person responsible for decisions. For example, a founder with a product idea and a clear first version. Or a company that runs on spreadsheets and now needs a proper system. A good first step is to write on one page what the system must do. If you need help, say so when you describe your project to us and we will find the answers together.
A SaaS platform keeps customer data separate with one of three AWS models. In silo, each customer has their own resources. In pool, customers share resources. In bridge, the two are combined. The model is chosen in the system design, before any code is written.
Read the articleThe roles and permissions of a SaaS are written before the code, as a table showing which role does what. The base is three OWASP rules: least privilege, deny by default and a check on every request at the server. The result is verified with tests.
Read the articleIn test-driven development (TDD), you first write a test that fails, then the code that passes it, and finally you improve the code. This way every feature of a SaaS platform has its check from the start. Most tests are small and fast, while a few check the whole in the browser.
Read the articleWe suggest it and you approve it. The suggestion is based on the requirements: how many users, which connections, how many years the system must run. We explain the reason for each choice in plain words.
Yes. The first step is the same: we study and record what exists and write down what it must do. Then we suggest whether to improve it or build it again from scratch. The suggestion is based on what we saw.
A system in operation, together with the handover of the last stage: what you need to run it yourself or with your team. Exactly what it includes is written in the project scope you approve at the start.
Changes are normal and go through the approval points of each stage. We record the change, explain how it affects the work and you decide whether it goes ahead.
Yes, if you wish. The AWS infrastructure covers hosting, a filter for harmful traffic and log files that are easy to read.
Send a project request, or check your current website for free. We read every message ourselves.