How Alevi Group approaches a custom SaaS build
A SaaS platform is a product other people will live in. The first release should be narrow, real, and safe to trust.
By Alevi Group ·
A custom SaaS build, in the way Alevi Group uses the phrase, is not a website with a login bolted on. It is software that other organizations will depend on for their records, their customers, their money, and their Monday morning. Alevi Group LLC takes that work on for clients, and we hold the same standard for the products we intend to ship ourselves. The studio stays small on purpose. The software should not be careless just because the team is.
This is the approach we actually use. It is not a case study. There is no invented client, no borrowed metric, and no before-and-after. If a number is not ours to publish, it does not appear here. What follows is the sequence of decisions that keeps a SaaS platform from becoming a demo that cannot survive its first real customer.
Start from the job, not the stack
The first conversations are about the work the software has to hold. Who signs in. What they are trying to finish. What happens when two of them disagree. What "done" looks like on an ordinary Tuesday, not on a slide. Frameworks come later. Alevi Group will choose a modern stack and say why, but the stack is not the product. A tenant, a permission, and a bill are the product.
We write the job down in plain language before we write a schema. If we cannot describe the core object of the system in a sentence a new teammate could repeat, we are not ready to build. The core object is the thing the business revolves around: an engagement, a policy, a shipment, a classroom, a portfolio. A feature that does not touch it, the permission around it, or the reason someone pays is a candidate to leave out of the first release. We also ask what people use today. Replacing a tool that almost works is not automatically an improvement.
Tenancy is not a setting
In a SaaS platform, tenancy is the promise that one customer's world cannot leak into another's. Alevi Group treats that as a design problem, not as a filter we hope every query remembers. Every screen, every file, every export, every background job, and every support tool has to know which tenant it is serving. The dangerous bugs are the quiet ones: an admin screen that lists "all rows," a CSV that forgets the filter, a log line that includes someone else's email address.
We decide early how a tenant is identified, how a person belongs to one or more of them, and what happens when someone is invited, removed, or leaves the company that pays the invoice. Those are not edge cases. They are the first month of real use. Uploads, exports, and background jobs sit inside the same boundary. If a file can be fetched by guessing a URL, the boundary is already broken.
Permissions before the feature list
A feature without a permission model is a demo. Before the screens people get excited about, we name the roles and the few actions that matter: who can see, who can change, who can invite, who can pay, who can export. The first set stays small. A role that can administer the account, and a role that can do the daily work, is often enough. Extra roles can wait until a real customer asks for a distinction that changes behavior, not just a label.
Support access, if it exists at all, should be explicit, limited in time, and visible to the customer. A quiet back door is not a convenience. It is a future incident.
Billing is part of the interface
If the product charges money, billing is not a plugin we attach at the end. Plans, trials, seats, usage, failed cards, and the moment a subscription lapses all change what the software is allowed to do. Alevi Group designs that path with the same care as the main workflow. A customer who cannot pay should see a clear state, not a broken page. A customer who upgrades should receive the thing they paid for without writing to us to ask whether it worked.
We would rather launch with one honest plan than with five tiers we have to apologize for. If a third party processes the payment, the account should be opened in the name of the organization that owns the product.
The first release is a thin, real product
Version one should do the core job completely for a narrow set of people. It should not do half of ten jobs. We cut anything that does not change the core object, the permission around it, or the reason someone pays. Notifications, integrations, and exotic reports are usually second. A reliable invite, a reliable save, and a reliable export are first. If those three are shaky, nothing else will feel finished.
Names and fields we have only seen once stay easy to revise. Tenancy, identity, billing identity, and data ownership do not. Speed on those is a debt the next year has to pay.
What the client owns
Alevi Group builds so the client can keep the work. The repository, the production project, the domain, the billing account, and the keys should sit with the organization that will live with the product. We do not hold a client's business hostage to a studio login. Where a third party is involved, we say so in writing. Our own products are different only in who owns them. The care is the same.
When an Alevi Group product is ready to be named and used, it will be published on its own page, with its own description, and with a public record that matches something a person can actually open. Until then we will not pretend a placeholder is a launch. The work page describes the practice. It does not invent a catalog.
What we will not call a SaaS
If the users are really one internal team, and nobody is going to subscribe, a multi-tenant platform is a costume. A well-made internal tool is still custom software, and we will say so. We also will not pretend a SaaS is finished when the happy path looks good in a meeting, and we will not publish quotes or numbers we do not have.
If you are considering a platform like this, the useful first note is a description of the job, who it is for, and what you already use. Write through the contact page or to sales@alevigroup.com. If you are still deciding whether the product should be a website, an installed web app, or a native client, read how Alevi Group chooses. The way a project is sequenced once it starts is in how an Alevi Group project runs.