Null Lines Pte Ltd · Singapore · delivery log
Work and case notes
The kinds of products and systems we have delivered — what the scope was, which platform it ran on, and what it had to connect to.
Notes written the way we would brief a colleague
These are the kinds of products and systems Null Lines has delivered, described in practical terms: what the scope was, which platform it ran on, and what it had to integrate with. We have kept the notes specific, because the details are what tell you whether a team has done work like yours. Client names are omitted where an engagement is confidential.
Read them as a checklist for your own conversations. When a studio tells you about a build, the useful questions are about the systems it touched, who had access to what, and what happened when something on the other side changed. Those answers are harder to dress up than a portfolio screenshot.
Customer portals
A recurring project type is the customer portal: a logged-in area where your customers check status, submit requests, or manage their account. We have built portals that sit in front of existing back-office systems, pulling live data through an integration layer rather than duplicating it.
For a Singapore service business, that meant customers could see their job history without calling the office. The build covered authentication, role-based access, and the API work to reach the internal system. It is the kind of project where the integration is most of the effort — the screens are the easy part to describe and the hard part to get right once real data arrives in them.
Portals also raise questions worth settling early: who can see whose records, what happens when a customer changes their email, and how a support person corrects a mistake without editing the database by hand.
Scope shape
- Authentication and roles
- Live data from the back office
- Request and status history
- Staff-side correction tools
the integration is most of the effort
Internal dashboards
Another common build is the internal dashboard that replaces a manual process. One example: a team tracking jobs and stock across spreadsheets, where nobody trusted the numbers by Friday. We built a dashboard that pulled from the operational systems, showed current status, and let staff update records in one place.
The value was not in the visual design; it was in having one version of the truth. Dashboards like this often start small and grow as the team finds more uses for accurate data. The first release usually covers the two or three numbers people argue about most, and later releases handle the reporting and export work that used to happen at month end.
What changes in practice
nobody trusted the numbers by Friday
Mobile apps for field teams
We have worked on mobile apps for teams that operate away from a desk: staff who need to log jobs, capture information, or report status from a phone. These apps connect back to a central system, so the office sees updates as they happen rather than at the end of the day.
Native or cross-platform development is usually the right call here, because offline handling and device features matter. The work includes the sync logic and the conflict handling that keeps field data and central records consistent — the part that decides whether a technician on a weak signal loses an afternoon of entries.
SaaS platforms
For founders building a product to sell, we have worked on SaaS platforms that need to serve multiple customers from one system. The early architecture decisions, around tenancy, permissions, and billing, carry a lot of weight. We have built platforms where the account model and access control were designed before the first feature, which made adding customers a configuration step rather than a rebuild.
The front end, the back end, and the integrations were all part of the same delivery. That matters more than it sounds: when one team owns the whole path from sign-up to invoice, the seams between those parts get designed instead of discovered.
Decisions that arrive early
Enterprise integrations
Some projects are less about a new interface and more about connecting systems that were never meant to talk. We have built integration services that let a modern application read from and write to older platforms, handling the mismatches in data format and the limits on how often a system can be called.
In regulated environments, that work comes with extra requirements around audit trails, access control, and reliability. The integration layer is often invisible to end users, and it is where the project is won or lost. A screen that loads a second slower is an inconvenience; an integration that writes the wrong record is a problem nobody forgets.
Where the difficulty actually sits
Progressive web apps
Not every project needs a native app. We have delivered progressive web apps where the audience arrived through the browser and a store download would have added friction. These run on the web, can be installed to a home screen, and serve the same purpose as a simple app without the two-platform overhead.
They suit booking tools, portals, and information services. Where a product later needs device features, we can plan the move to a native or cross-platform build — and because the data layer is already separate from the interface, that move is a smaller job than starting over.
Choosing the delivery shape
Progressive web app
Browser-first audience, fast to reach, installable, one codebase.
Cross-platform app
Shared codebase with access to device features and offline storage.
Native app
Full platform integration where the workflow depends on it.
Most of the value in a business application comes from what it connects to.
ask what they had to integrate
What these notes tell you
the scope notes are the part worth asking about
The common thread across these projects is integration. Most of the value in a business application comes from what it connects to and how reliably it does so, not from the surface. When you are assessing a development team, ask what they had to integrate and how they handled the constraints, because that is where projects run into trouble. The scope notes above are the kind of detail worth asking about in any portfolio.
A useful second question is who maintained the thing afterwards. A build that only its authors can safely change is a liability, so ask what documentation was handed over, how environments were separated, and what the team was shown before the work was called done.
Questions worth asking
The same questions come up on almost every project, so here they are answered in plain terms.
Can you tell me which parts of a build are hardest?
Usually the integration work and the rules around access. Anyone can describe a screen; the harder conversation is about where the data lives, who is allowed to change it, and what the older system will tolerate. Ask for that in the first meeting.
Why are client names left out of some notes?
Some engagements are confidential, so we describe the shape of the work instead. The scope, platform, and integration context are the parts that help you judge fit; a name alone rarely does. Where a client is happy to be named, we name them.
Do you only take on large projects?
No. Portals and dashboards often start as a focused first release with a small number of screens, then grow. What matters is that the first release is built so the second one does not require undoing it.
What should we have ready before a first conversation?
A description of the process you want to improve, the systems it touches, and who uses them day to day. A rough list of the people who will need access is more useful than a finished specification.
If your project looks like one of these
Tell us what you are trying to build, which systems it has to reach, and who will use it. We will tell you honestly whether it looks like a portal, a dashboard, a mobile app, or a platform — and where we think the difficulty will sit. If you want to talk through how this applies to your project, the contact page is open.
Where to find us
bring the messy process, not the tidy one