01 / 04
Data: What the system must know
Before UI, before features, before brand - we map what the system needs to know. A weak data model cannot be rescued by clean code on top of it.
What you receive at handover
- Database schema
- Migration history
Approach
Our web development approach:
data first, page last.
The order Altruvex makes technical decisions in: data first, then architecture, then features, then the page. Each layer is settled before the next is built on it.
Usually
The pageFeaturesArchitectureData02 / 04
Architecture: How it holds up
Architecture precedes implementation.
Design for ten times the load
Few projects will reach it, but growth assumptions change every architectural decision made today.
Write for the next engineer
Code written for one person is fragile. Every commit assumes someone else will read and extend it six months from now.
Keep intervention cheap
A system that needs constant attention is not finished. We build for long stretches of stability where nothing breaks and nothing drifts.
- Usually said
- Get it working, optimize later
- Said here
- Define architectural constraints before opening the editor
- Usually said
- We will fix it after launch
- Said here
- Launch is when the system starts working - not when fixes start
What you receive at handover
- Architecture decision log
- Deployment documentation
03 / 04
Features: What gets built, and what does not
Constraints are a design tool.
Every project starts by deciding what will not be built: the features out of scope and the use cases excluded. Your proposal states that scope, so you can check the build against it.
A system designed for everyone serves no one well. Fewer, deliberate features are faster to build, test and change.
- Usually said
- Build the features users asked for
- Said here
- Understand the problem users are actually trying to solve
What you receive at handover
- Git repository in an account you control
- Guide to environment variables and secrets
04 / 04
The page: Decided last
The page is the last thing we decide, because it is the one layer that stays cheap to change.
Right-to-left is decided in the architecture at the start, instead of being added at the end by flipping the layout. Every component, layout and interaction is built and checked in both directions.
Arabic is adapted, not translated: navigation, alignment and reading order are reconsidered for an Arabic reader.
One heading, two directions
English · left to right
Structure that respects direction.
Arabic · right to left
تصميم يحترم اتجاه اللغة.
- Line height
- Arabic headings get more room than Latin ones, so dots and tall letters never collide.
- Letter spacing
- Never added to Arabic. Spacing breaks the joins between letters.
- Direction
- Arrows, lines and order follow the reading direction, not the edge of the screen.
What you receive at handover
- Both languages in one codebase
- Source code as it runs in production
What we will not do.
Five things we turn down, so you know before you ask:
- 01
Fixed deadlines set before the scope is known
- 02
Systems we could not stand behind technically
- 03
White-label work through another agency
- 04
Competing on price alone
- 05
Building before the problem is mapped
Next step
If this is how you want it built, start with the problem.
Describe what you are building in a few lines. You get a direct technical answer on scope, cost and fit.