Why building is exciting now
We could do much of this before. What has changed is whether it is worth choosing. Why we are revisiting the blockers we met after SaaS adoption, and what we check more carefully as we build faster.
This is the second of two articles. In the first, We adopted it to reduce work, and it created more, we described the problems we kept running into while building and proposing SaaS. This one is about how we see those problems now.
Our team is enjoying going back to blockers we could not settle for a long time. Approval states that differ from one system to the next, permission settings that need rework after a reorganization, and a person stepping in to clean up when one step fails midway are not unfamiliar problems for us. But looking at them now feels different from before.
It was possible, but hard to choose
To build an integration or exception handling for a particular customer, you first have to understand that company’s environment. You need to know how its existing systems run, where exceptions come from, and who approves what by which rules. Then you build, test and revise. When that takes a lot of time, it is hard to justify building a different exception for each customer. It cannot go into a shared product that has to fit everyone, and building it separately for each customer does not pay for itself, so the difference stays with people to fill.
It was not technically impossible. It was possible before. What changed is time and cost. Using AI and development tools, our team has seen the time and cost of repeating analysis, implementation and verification drop markedly. So an exception that differs for each customer can now be on the table.
Revisiting where we used to stop
When you work on integration, you sometimes reach a point where the other system offers no usable way to connect. In those cases you can automate the screen to perform the steps a person used to do, or analyze the traffic (packets) the systems exchange to understand how they behave. We had set these aside because the cost of understanding the environment and testing did not add up. Being able to reopen those points is what we enjoy most right now.
We consider these methods too only within the systems and accounts the customer has allowed, and within their security requirements and terms of use.
This is also only one option among several. If an official integration exists, that is the better path, and if the problem can be solved by changing a procedure or a setting, that is the right answer. We are not suggesting AI everywhere. AI is a means to solve the problem, not a requirement. The faster the tools get, the more it matters to judge what to use where, and to draw on field experience when making that call.
What we check more carefully as we build faster
Once building gets quick, the difference between something that works once and something you can keep relying on matters even more. So after building, we want to check things like these:
- whether we notice right away when the other system’s screen or response changes
- whether a failure shows up for the person responsible instead of being buried
- whether sending the same request again avoids processing the same item twice
- whether it is recorded who did what with which permission, and who takes responsibility and makes the call when something goes wrong
The cost has not disappeared either. What we build has to be maintained, and if the new tool becomes one more maintenance job, we have repeated the problem from the first article. So we hold to one standard: did this reduce the customer’s actual work? We are still working on this problem, and we are adding what we confirm along the way, one thing at a time.
When lapal lab says Beyond advice. We build., it does not mean advice is unimportant. It means going past advice to building and checking. Being able to propose to a customer, “Let’s build this and check it,” is why now is exciting for us.
Previous article: We adopted it to reduce work, and it created more