I build Django systems where business rules, data integrity, and maintainability matter.
Most of my serious work lives in private repositories: ERP-style systems, site/project management tools, finance workflows, restaurant and retail operations, inventory tracking, reporting, and internal dashboards.
This profile is here to make that work understandable from the outside.
- Operations systems for real businesses, not toy demos
- Django backends with admin workflows, permissions, reports, and audit trails
- Inventory, finance, attendance, project, restaurant, retail, and ERP-style modules
- Data models that represent real rules: stock movement, balances, approvals, payments, and user actions
- Interfaces that help staff enter, review, and act on business data quickly
- Building cleaner Django service layers
- Improving test coverage for business-critical behavior
- Turning private-system experience into public, reviewable portfolio projects
- Practicing production habits: small scopes, explicit constraints, readable docs
| Area | What I have been building |
|---|---|
| ERP and operations | Multi-module systems for business records, inventory, users, dashboards, and reports. |
| Finance workflows | Ledgers, account-like structures, payment tracking, and correctness-focused backend logic. |
| Site and project management | Tools for tracking work, materials, contractors, logs, and operational progress. |
| Restaurant and retail | Order, stock, sales, menu/product, and daily reporting workflows. |
| Device/data integrations | Python investigation and bridge work around attendance/device data flows. |
| Project | Why it matters |
|---|---|
| restaurant-management-system | Public Django + React example for orders, inventory, payments, and reporting. |
| bridge-zkemkeeper | Python integration and investigation work around attendance/device data. |
| double-entry-core | Public reference for financial domain modeling and double-entry accounting rules. |
| spotter-frontend | Deployed frontend work showing React product UI practice. |
- Model the domain before adding screens.
- Keep business rules close to tests.
- Make names boring, specific, and searchable.
- Prefer small working slices over large unfinished systems.
- Treat README files as part of the product, not decoration.
- Taking messy operational requirements and turning them into structured Django models.
- Building admin-first workflows that staff can actually use.
- Separating business logic from views, templates, and framework glue.
- Reading a business process carefully before deciding what the database should look like.
- Keeping systems understandable enough to extend after the first release.
Backend and data
Business systems
Frontend and workflow
I am based in Mogadishu, Somalia, and I am focused on becoming the kind of backend engineer who can be trusted with real operational systems.