How an Alevi Group project actually runs
A sequence, not a slogan. We do not publish a standard timeline, because the honest length depends on the work.
By Alevi Group ·
Alevi Group is a boutique studio. Projects here do not run on a secret methodology with a trademarked name. They run on a sequence we can say in public: understand the job, draw a boundary around the first release, build a thin slice that is real, and stay with it after it is in use. The length of each step depends on the work. Anyone who quotes you a universal number of weeks, before they have understood the job, is guessing for your comfort. We would rather be specific later than precise and wrong now.
This is the process we mean when we talk about custom software, a SaaS platform, or a mobile app. The same spine holds. The technical choices, including web, PWA, or native and the shape of a SaaS build, sit inside it. They do not replace it.
The conversation
We start with the job, not with a requirements document that pretends to be finished. Who is the work for. What they do today. What fails. What must not be lost: money, privacy, a legal record, a customer's trust. What "good" will look like when this is no longer a project and is simply the way the organization works.
A short note is enough to learn whether we are the right studio. We will say if we are not. Bring what you already use if you can. Artifacts beat adjectives.
The boundary
Once the job is clear enough, we draw a boundary around the first release. Inside the boundary is the smallest set of behavior that would let a real person finish the core task, safely. Outside it is everything else we can already imagine and are choosing not to build yet. Writing the outside list is as important as writing the inside one. It is how a project stays a project instead of becoming a place where every idea has equal claim on the next week.
The boundary includes what is expensive to undo: who can see what, how a record is corrected, where the data lives, and who owns the accounts. For a SaaS product, tenancy and billing sit inside this boundary even when the feature list is short. Leaving them until later is how later becomes a rewrite.
A thin slice that is real
We would rather put a narrow product in front of reality than a wide prototype in front of a meeting. A thin slice still saves, still signs people in, still respects permissions, and still looks like something Alevi Group is willing to put our name near. It is not a clickable picture of screens that throw the data away. Pictures are useful for a hard interaction. They are not a substitute for the path a person will walk every day.
The slice is also how we check the boundary. If the core task cannot be finished, we move the boundary in the open. Neighboring ideas get written down and wait. Memory is a poor specification.
Design in the product
The visual standard of Alevi Group is quiet on purpose. You can see it on this site: sand, black, one typeface, a lot of space. Product work does not have to look like the marketing site. It does have to be deliberate, at the size the work will actually be used. Empty states, errors, and waiting are part of that. A product that only considers the happy path feels broken in the first week, because the first week is mostly edge cases.
Build, review, and what gets written down
Building is ordinary on purpose. Small changes, reviewed, with the boundary nearby so we can tell when a change is a new idea in disguise. We do not measure progress by how many screens exist. We measure it by whether the core task is closer to something a stranger could finish without us in the room.
You should be able to see the work while it is underway: a staging environment, a repository you can read, a short note when something material changes. If a risk appears, we say it when we see it.
Release
A release is the day a real person depends on the software, not the day a demo looks complete. We prepare the accounts, the domain, the keys, and the way back if something is wrong. We decide what "wrong" means in advance: data loss, a broken sign-in, a payment that does not match, a tenant seeing another tenant. Those are stop-the-line events. A awkward label can wait until morning.
We do not announce a launch with numbers we do not have, and we do not ask anyone to pretend to be a customer. For Alevi Group, sales@alevigroup.com is the mailbox while a project is being formed, and support@alevigroup.com is the mailbox once a product is in someone's hands.
Care after the first day
Software that is in use will need care: defects, small changes, and the occasional decision that the boundary should move. We would rather agree that care exists than pretend a handover is a disappearance. The shape of that care depends on the engagement. Some clients want the studio to stay. Some want their own team to take the repository and call us only when it is worth it. Both are legitimate. What is not legitimate is a codebase nobody can run, on accounts nobody else can open.
Care also includes knowing when to stop. A product can be finished enough. What Alevi Group builds is three practices, not an infinite catalog.
What we need from you
A clear decision-maker. Access to the person who does the daily work, not only the person who sponsors it. Honest answers about what is required and what is taste. Timely review, because a project that waits weeks for a look at a thin slice will drift. And the willingness to cut. The boundary only works if both sides will defend it.
If that sounds like the way you want software made, write to us. The contact page is enough. Tell us the job, who it is for, and what you use today. We will answer as Alevi Group, not as a funnel.