< ENGINEER / >
M.ABU SALH
M.ABU SALH
About Me
N°02 / 07
MOHAMMAD
I build production web and mobile products end to end: from architecture and APIs to polished interfaces, testing, and deployment.
-
01
SaaS Delivery
Shipped a psychometric SaaS platform to production in five months as the sole developer.
-
02
Flutter App
Built and shipped a cross-platform Flutter app from a single codebase to both the App Store and Google Play.
Core Stack
- TypeScript
- React / Next.js
- Node.js / Express
- SQL
- NoSQL
- Docker
Also expert in GraphQL, Redis, WebSockets, and automated testing.
M.ABU SALH
III
Experience
N°03 / 07
Where I’ve
Worked
Three years across product startups and client work, moving from a single React site to owning a platform end to end.
-
01
Jan – Jul 2026 · 7 mos
Amman, Jordan · Remote
Full‑Stack Web Developer
The Little Genius
Shipped Inside Brain, a production psychometric assessment platform, solo in five months: engineered the TypeScript/GraphQL backend, built the Next.js product across six timed assessments, and shipped a Dockerized deployment scoring Lighthouse 100 for accessibility and SEO.
-
02
Jul 2024 – Feb 2026 · 1 yr 8 mos
Dubai, UAE · Remote
Software Engineer
Masaar Media
Ran technical SEO and performance audits across client sites, contributing to 30–40% page-speed and search gains, delivered responsive builds for 4+ clients, and built 3 GA4/GTM/Looker Studio dashboards.
-
03
Aug 2022 – Oct 2023 · 1 yr 3 mos
Bethlehem, Palestine · Hybrid
Web Developer
Students’ Forum Association
Built the association’s first proper web platform end to end, a React front end on an Express API, replacing an unmanaged patchwork of data.
M.ABU SALH
IV
Projects
N°04 / 07
Things I’ve
Built
A selection of shipped products spanning full-stack web apps, mobile, and backend tooling.
Selected Work
CompuCash
WordPress
POS marketing site
PPU Connect
Flutter · Firebase
Tutor matching app
Scrubli
Flutter · Suoabase
On-demand cleaning
K
Kamakan Middleware
Node.js · Go
POS data sync, zero loss
M
Clear Khutbah
Flutter · AI
Live sermon translation
T
Microservices Ticketing
NATS · Kubernetes
Event-driven system
IronFit
Flutter · Firebase
Gym management app
2
Class2Code
GraphQL · Neo4j
IEEE-published capstone
M.ABU SALH
V
Engineering Decisions
N°05 / 07
Problems solved
The reasoning behind consequential technical choices, including the constraints, trade-offs, and measured result.
01–02 / 06
Platform strategy · Performance
Avoiding an Unnecessary Platform Rewrite
A React product with performance, responsive UX, and SEO issues was headed toward a full WordPress rebuild of more than 40 existing pages.
Decision Diagnose and improve the existing implementation before replacing the platform.
- Pages retained
- 40+
- Desktop
- 5592
- Mobile
- 3884
Context
An existing React-based product had accumulated several visible problems:
- Poor UX/UI
- Weak responsiveness across devices
- Slow loading and low performance scores
- SEO issues
- More than 40 existing pages
- A highly interactive test experience with application-like behavior
A proposal was made to rebuild the website on WordPress. The main motivation was to improve content management, SEO, and the overall website experience.
The person advocating for the migration was already familiar with WordPress, which made it a natural solution from their perspective.
The Decision I Challenged
The proposed direction was effectively:
Existing React application → Full WordPress rebuild
I disagreed with the migration during three separate discussions.
My concern was not that WordPress was inherently a bad technology.
My concern was that we were about to replace an entire working system before proving that the platform itself was the cause of the problems we were trying to solve.
The actual problems were performance, UX/UI, responsiveness, and SEO.
A full rewrite introduced a much larger problem: rebuilding more than 40 existing pages and recreating a complex interactive experience simply to address issues that might be solvable inside the current system.
My Reasoning
I separated the problem from the proposed technology.
Should we use React or WordPress?
I focused on a more useful question:
What exactly is broken, and does fixing it require replacing the platform?
A complete migration would have meant:
- Recreating more than 40 pages
- Reimplementing existing functionality
- Rebuilding the interactive test experience
- Introducing a new regression surface
- Spending months reproducing functionality that already existed
- Delaying improvements that could potentially be delivered directly in the current application
Do not rewrite the system yet. Diagnose and fix the actual problems first.
Alternative Proposed
Instead of replacing the application, I proposed improving the existing implementation directly.
Diagnose → Optimize → Measure → Re-evaluate
Image Optimization
Images were resized appropriately instead of serving unnecessarily large assets. Formats were improved, including using WebP where appropriate. Lazy loading kept images outside the initial viewport from loading immediately.
Reducing Initial Dependency on External Data
I reduced situations where the initial user experience unnecessarily waited for external data before allowing the page to become usable. External dependencies became less capable of blocking perceived loading.
SEO Foundations
The existing application was improved instead of assuming SEO required a new platform. This included adding and correcting technical discovery mechanisms such as robots.txt and the sitemap.
Responsive Experience
The existing UI was improved to behave correctly across devices and screen sizes instead of treating the mobile experience as an afterthought.
Outcome
After further research and discussion, the team abandoned the proposed WordPress migration. We kept the existing application and improved it instead.
The measured performance score improved from 55 to 92 on desktop and from 38 to 84 on mobile.
The site also became faster to load and more usable across different screen sizes. Instead of spending months recreating more than 40 pages, the team retained the existing system and addressed the problems directly.
Why This Decision Matters
The important part of this decision was not choosing React over WordPress. It was refusing to confuse a problem in an implementation with a problem in the underlying platform.
A rewrite can feel attractive because it creates the impression of starting clean. But a rewrite is justified only when the expected value of replacing the system outweighs the cost, risk, and effort of rebuilding what already works.
In this case, the problems could be substantially improved without replacing the product.
Engineering Principle
Do not replace a system merely because it has problems. First determine whether those problems actually originate from the system's architecture or from fixable implementation decisions.
Or more simply:
Fix the constraint, not the technology you happen to dislike.
What This Demonstrates
- Separate the problem from the proposed solution.
- Understand the root cause before selecting technology.
- Estimate the cost of change, not only the attractiveness of the new solution.
- Prefer the smallest change capable of producing the required outcome.
- Measure the result instead of defending the decision through opinion.
The goal is not to be the engineer who always argues against rewrites. The goal is to be the engineer who can answer:
What problem are we actually solving, why is this solution appropriate, what will it cost us, and how will we know whether the decision worked?
AI architecture · Integration boundaries
Decoupling an AI Workflow from a Single Provider
A LangGraph workflow needed a company API, but direct integration would let provider schemas, authentication, errors, and business rules leak into the core.
Decision Put an internal capability contract and provider adapters between the AI workflow and external APIs.
- Core workflow
- Provider-neutral
- New provider
- Adapter only
- Testing
- Isolated
Context
I was working on a shared AI project built with LangGraph. The system needed to interact with an external company's API as part of the AI workflow.
During the planning phase, the most direct implementation would have been:
LangGraph workflow → Company API
That approach would have been simple initially, but it created an architectural risk. The product was not expected to remain tied to a single company forever. Other companies could eventually connect their own systems, APIs, schemas, authentication mechanisms, and business rules.
The problem was therefore not:
How do we connect LangGraph to this API?
The more important question was:
What happens to the core AI workflow when the next company's API looks completely different?
The Risk I Identified
If the LangGraph workflow depended directly on the first company's API, details specific to that provider could gradually leak into the core application.
- Provider-specific field names
- Request and response structures
- Authentication behavior
- Error formats and endpoint assumptions
- Status values and integration-specific business rules
LangGraph Workflow
|
+ Company A request and response mapping
+ Company A status and error handling
+ Company A assumptionsThat would work for the first integration. But when another company was introduced, the system could start accumulating provider-specific branches:
if provider == CompanyA: ...
elif provider == CompanyB: ...
elif provider == CompanyC: ...At that point, adding integrations would no longer be an integration-layer concern. It would require repeatedly modifying the AI workflow itself.
The Architectural Question
I wanted the core LangGraph workflow to understand the business capability it needed, not the implementation details of the company providing that capability.
Instead of asking:
Which endpoint should this graph node call?
I reframed the problem as:
What contract does the AI workflow actually require from an external system?
That distinction led to the architectural decision.
Decision
I redesigned the integration around an adapter layer. Instead of allowing LangGraph to communicate directly with a specific provider API, the workflow communicates through an internal contract.
LangGraph AI Workflow
|
| Internal Contract
v
Integration Layer
|
+-----+-----+
| | |
Adapter A B C
| | |
Company A B C APIsEach adapter is responsible for translating between the application's internal model and the external provider's model.
Responsibilities of the Adapter
Provider-specific concerns stay behind the adapter boundary.
External API response
v
Provider Adapter
v
Internal normalized representation
v
LangGraph workflowLangGraph action
v
Internal integration contract
v
Provider Adapter
v
Provider-specific API requestThis allows the core AI workflow to remain focused on reasoning, state transitions, orchestration, decision logic, and business behavior rather than external API details.
Why I Chose This Approach
The goal was not to introduce a design pattern simply because an adapter is considered a good practice. The abstraction addressed a specific expected source of change.
The external provider was likely to change. The core business workflow should not need to.
Put the abstraction at the boundary where variation is expected.
Instead of trying to make every part of the system generic, I isolated the part most likely to differ between companies.
Alternatives Considered
Direct Integration
The simplest initial implementation was LangGraph calling the company API directly. It offered faster initial delivery, fewer abstractions, and less code at the beginning.
The problem was that the core workflow would become aware of the first provider's API model. Adding another provider could then require changes throughout the graph. Short-term simplicity could become long-term coupling.
Provider Logic Inside the Workflow
Provider conditions could live directly inside LangGraph. This could work with very few integrations, but it makes orchestration responsible for AI reasoning, business logic, API mapping, provider selection, error translation, and integration behavior.
The workflow would become increasingly difficult to reason about.
Chosen Boundary
CORE
LangGraph, AI behavior, business workflow, internal domain model
INTEGRATION BOUNDARY
Internal interface / contract
EXTERNAL
Adapter A -> Company A
Adapter B -> Company B
Adapter C -> Company CThe core depends on an internal capability, not on a specific provider.
Expected Change Model
With direct coupling
New provider
v
Modify LangGraph
v
Add conditions and mappings
v
Modify error handling
v
Retest core workflowWith adapters
New provider
v
Implement new adapter
v
Map behavior to internal contract
v
Reuse existing core workflowThe core does not need to know whether the external implementation is Company A, Company B, Company C, or a future system that does not yet exist.
What This Decision Prevented
Provider Lock-In
The AI workflow would not be designed around one company's API.
Integration Logic Leaking Into AI Logic
LangGraph nodes would remain focused on orchestration rather than API translation.
Growing Conditional Complexity
Supporting additional companies would not require spreading provider checks across the workflow.
External Schema Contamination
External field names and structures would not become the application's internal domain model.
Expensive Future Refactoring
The boundary was introduced while the architecture was still being designed, before multiple providers became tightly coupled to the system.
Trade-Offs
The adapter architecture was not free. It introduced an additional abstraction, more interfaces, mapping logic, additional test boundaries, and slightly more initial implementation work.
For a product permanently connected to only one external API, this abstraction could have been unnecessary. It was justified here because supporting systems from other companies was a realistic architectural requirement.
The additional complexity was placed specifically where future variability was expected.
Testing Strategy
The separation creates clearer testing boundaries. The core workflow can be tested against the internal contract with a fake adapter, without requiring the real provider API.
Provider adapters can be tested independently for request mapping, response normalization, authentication, API errors, malformed responses, timeout behavior, and provider-specific edge cases.
This keeps failures in external integrations from unnecessarily contaminating tests of the AI reasoning workflow.
Confidentiality
This project involved a real company integration. For confidentiality reasons, the company, business domain, API details, data structures, and internal project information are intentionally omitted.
The architectural decision can still be explained without exposing proprietary information. The important engineering problem was not the identity of the provider. It was the system boundary.
Engineering Principle
Do not let an external system define the architecture of your core application.
External APIs, partners, schemas, authentication, and business integrations change. The core system should absorb as little of that volatility as possible.
Abstract around expected change, not around hypothetical complexity.
I did not attempt to make the entire system generic. I isolated one boundary because there was a concrete reason to expect multiple implementations behind it.
The Standard I Wanted
Adding another provider should require another adapter, not another version of the AI workflow.
That became the test for whether the boundary was designed correctly.
What This Demonstrates
- Identify coupling before it becomes expensive.
- Separate stable business logic from volatile external infrastructure.
- Design around contracts rather than vendor-specific implementations.
- Use abstractions only where there is a credible source of variation.
- Keep orchestration focused on orchestration.
- Prevent today's fastest integration from becoming tomorrow's architectural constraint.
The important decision was not "Use the Adapter Pattern." It was:
Recognize which part of the system was likely to change, and prevent that change from spreading into the core architecture.
Integration reliability · Failure recovery
Recovering Failed Records Without Replaying the Entire Sync
A scheduled invoice and POS sync could complete most records successfully while a small subset failed because of validation, remote API, or data-mapping errors.
Decision Preserve successful work, isolate failed records, and retry only the unresolved subset.
- Failure scope
- Per record
- Replay scope
- Failed only
- Recovery state
- Redis-backed
Context
Kamakan Middleware moves sales invoices, products, and inventory between a POS platform and an internal backend. Some operations run on a schedule. Others start from the dashboard or from changes arriving in the application.
The awkward part was not sending a request. It was deciding what a failure meant when a batch contained hundreds or thousands of independent records.
A bulk request could create most invoices and reject a few. A POS push could update one product, fail on the next, and continue successfully after that. Treating those outcomes as a single success or failure would discard useful information.
The failure model I rejected
The simplest recovery plan was to fail the whole job and replay the complete batch. That sounds safe until successful records already exist.
- Replaying successful records increases traffic against systems that already completed the work.
- Duplicate protection becomes responsible for cleaning up a recovery strategy that is too broad.
- One bad record can keep forcing good records through the same pipeline.
- Operators see a failed job but still do not know which records need attention.
The system needed to distinguish a transport failure, where the operation could not complete at all, from a partial data failure, where only specific records remained unresolved.
The decision
Preserve confirmed progress and make the failed subset the unit of recovery.
The backend reports created, skipped, and failed invoice records separately. Duplicate invoices are skipped rather than turning a safe replay into another failure. The API accepts batches of up to 2,000 invoices, but it does not pretend that every item in a valid request has the same outcome.
The Go scheduler reads the item-level errors, extracts only the failed invoices, and retries that smaller set. It carries their original indices forward so a later error still points to the correct record in the source batch.
Two recovery paths
Whole operation failed
POS fetch or backend call fails
v
Immediate retry tier
v
Delayed retry tier
v
Final failure alertIndividual records failed
Bulk request completes
v
Extract failed indices
v
Retry failed subset
v
Log unresolved recordsImmediate retries cover short interruptions. Delayed retries cover outages that need time to clear. Partial retries do neither blindly; they operate on the records the backend explicitly rejected.
Keeping POS failures recoverable
Product and inventory pushes use the same principle with a different mechanism. Push jobs run one at a time through a queue, preventing overlapping jobs from writing competing state. Each run records successful and failed items separately and publishes a partial status when both are present.
Failed product IDs and inventory adjustment numbers are merged into a Redis-backed cache. A successful retry removes the corresponding entry. Retry counts stop permanent failures from cycling forever, and the cache evicts its oldest entries when it exceeds the configured limit.
An in-memory implementation follows the same contract when Redis is not configured, which keeps unit tests isolated without changing the recovery behavior being tested.
Operational visibility
Recovery is only useful if the result is visible. Kamakan records success, partial success, and final failure as different states. Logs retain counts and failed-item details. WebSocket events update the dashboard, while email alerts identify invoice records that remain unresolved after the configured retry rounds.
This gives an operator a list of remaining work instead of a generic message that the nightly sync failed.
Trade-offs
Item-level recovery adds state. Error indices must be remapped. Failed records need bounded storage. Retry counts and race conditions require tests. A single all-or-nothing status would be easier to implement.
The extra machinery is justified because these records are independent and the external systems can fail independently. Preserving a completed record is safer than repeatedly treating it as unfinished.
Engineering principle
Recovery scope should match failure scope.
When one request fails, retry the request. When three records fail inside a successful batch, retry those three records. Broad recovery is not automatically safer; sometimes it only repeats work the system has already confirmed.
What this demonstrates
- Model partial failure as a normal system state.
- Preserve progress instead of using rollback as a reflex.
- Make retries selective, bounded, and observable.
- Keep recovery state durable without coupling tests to infrastructure.
- Design operator feedback around the records that still need action.
Service boundaries · Operational control
Separating Scheduled Integration Work from the API
Long-running schedules, delayed retries, external POS calls, API traffic, persistence, and live dashboard updates had different runtime and failure characteristics.
Decision Keep orchestration in a Go scheduler and application responsibilities in the Node.js API, connected through explicit HTTP and Redis contracts.
- Orchestration
- Go service
- Application API
- Node.js
- Config signal
- Redis Pub/Sub
Context
Kamakan needed an application API and an integration runtime. Those responsibilities touched the same business data, but they did not behave like the same process.
The API serves authenticated requests, validates payloads, writes to SQL, exposes dashboard data, and publishes live events. The integration runtime wakes on a schedule, calls an external POS, waits between retry rounds, transforms records, and can remain busy long after an HTTP request should have ended.
The coupling risk
Putting cron execution inside the Node.js API would have reduced the number of services, but it would also have joined unrelated lifecycles.
- An API deployment could interrupt a delayed integration retry.
- A slow POS call could compete with interactive traffic for the same process resources.
- Scaling the API could accidentally create multiple schedulers.
- Scheduler configuration and health would become application-process concerns.
The language was not the important decision. The lifecycle was.
The boundary
GO SCHEDULER
Cron and timezone
POS extraction
Retry timing
Transformation
Operational alertsNODE.JS API
Authentication
Validation
SQL persistence
POS push state
Logs and WebSocketsThe scheduler owns work whose duration is controlled by time and external systems. The backend owns application state and the contracts used by people, the dashboard, and other services.
Scheduler responsibilities
The Go service loads the configured timezone and cron expression, fetches the previous invoice window from the POS, transforms provider records into the backend contract, and coordinates full and partial retries.
It also exposes a health port, reports job outcomes to the backend, triggers recovery of prior POS failures when safe, synchronizes inventory, and sends alerts after retry exhaustion. None of those operations needs to keep an incoming browser request open.
Backend responsibilities
The TypeScript backend remains the authority for authentication, request validation, SQL models, invoice and product APIs, operation logs, notifications, POS push state, and WebSocket updates.
The scheduler does not write directly into the application's database. It uses authenticated HTTP endpoints, which keeps validation and persistence rules in one place.
Communication contracts
HTTP carries commands and results that require a response: bulk invoice creation, job logs, current push status, and retry triggers. Redis Pub/Sub carries scheduler configuration changes, where the important event is that new configuration is available.
Dashboard changes schedule
v
Node.js persists configuration
v
Redis publishes config-changed
v
Go scheduler reloads and reschedulesThe scheduler also falls back to fetching configuration from the backend, so Pub/Sub improves responsiveness without becoming the only source of truth.
Operational behavior
Docker Compose gives each service its own image, environment, restart policy, health surface, and bounded log files. The API can be deployed for route or dashboard changes without redefining the scheduler loop. The scheduler can restart after an integration fault without taking authenticated application traffic with it.
Separate services also make failure ownership visible. A scheduler health failure means something different from an API health failure, and operations can respond accordingly.
Trade-offs
The split adds deployment units, authentication between services, versioned request contracts, network failure handling, and more local setup. A single process would have less wiring.
I accepted that cost because the work already had separate timing, scaling, and failure behavior. Keeping it in one process would hide the boundary without removing it.
Engineering principle
Split services by runtime responsibility and failure mode, not by language preference.
Go is useful here because it provides a small, direct scheduler runtime. Node.js is useful because the application and its existing API ecosystem already live there. Neither language is the architecture. The ownership boundary is.
What this demonstrates
- Separate interactive application work from time-driven orchestration.
- Keep persistence rules behind one application contract.
- Choose communication mechanisms according to message semantics.
- Design deployments around independent health and restart behavior.
- Accept distributed-system costs only when the operational boundary is real.
Distributed systems · Realtime reliability
Preventing Realtime Events from Becoming Ghost State
Aura 4 had to commit application state in PostgreSQL and notify connected clients through Centrifugo without letting either system tell a different story.
Decision Commit the state change and its publication intent together, then deliver the event through an independent outbox relay.
- Source of truth
- PostgreSQL
- Delivery pattern
- Transactional outbox
- Realtime broker
- Centrifugo
Context
Aura 4 uses PostgreSQL as its source of truth and Centrifugo to push changes to connected team members. A completed task, a new handover, or an updated loop must produce one consistent result across the API response, the database, and every active client.
The difficult part is that PostgreSQL and Centrifugo are separate systems. A normal database transaction cannot include a broker publish. Treating those two operations as one step inside a request would hide a dual-write problem rather than solve it.
The unsafe path
The simplest implementation would save the business change, publish an event, and return success. That sequence has two failure windows.
State commits, publication fails
The database contains the change, but connected clients never hear about it. Their screens remain stale until another refresh or reconciliation.
Publication succeeds, state rolls back
Clients receive an event for a change that does not exist. The interface displays ghost state and may build later actions on a false premise.
Retrying the request does not close either window. It can also repeat the database mutation or publish the same event more than once.
The decision
I made the database transaction responsible for two records: the business change and an unpublished outbox event describing that change.
Business write + outbox row in one PostgreSQL transaction
If the transaction rolls back, neither record exists. If it commits, the system has durable proof that an event still needs to be delivered. The request no longer depends on Centrifugo being available at that exact moment.
Independent delivery
An outbox relay reads unpublished rows, routes each event to the correct channel, publishes it through the broker adapter, and marks the row as published.
Failed publication remains visible as pending work. The relay can retry it without repeating the original business transaction. Because a crash can occur after publishing but before marking the row, delivery and consumers must tolerate duplicate attempts.
This changes the guarantee from an unsafe attempt at exactly-once delivery to a durable, observable at-least-once process.
Operational consequences
The outbox adds a relay process, retry behavior, event routing, duplicate tolerance, and ordering rules. It also creates a useful operational boundary.
- Unpublished rows expose delivery backlog instead of hiding it in request logs.
- Outbox lag measures the distance between committed state and realtime visibility.
- Broker failure can degrade live updates without corrupting the underlying state.
- The broker remains replaceable behind the existing publisher contract.
Trade-offs
Publishing directly from the request has less code and can shave time from the happy path. The outbox requires another worker and more operational attention.
I accepted that cost because realtime speed is useful only when the event is true. A slightly later correct update is safer than an immediate event that can disagree with committed state.
Engineering principle
Persist the event commitment with the state change. Publish it independently.
What this demonstrates
- Recognize a dual write before it becomes a consistency incident.
- Place atomicity inside the system that can actually guarantee it.
- Design retries around durable work instead of repeating user requests.
- Make delivery delay measurable through backlog and outbox lag.
- Keep the realtime broker outside the business transaction boundary.
Product architecture · Complexity control
Modeling Real Blockers Instead of Building Dependency Spaghetti
A conventional dependency graph promised advance planning, but it also asked teams to maintain speculative relationships before Aura 4 had evidence that the model matched their work.
Decision Record observed blockers as owned Loops and defer dependency inference until real operating history can validate it.
- Evidence model
- Observed blockers
- Responsibility
- Explicit ownership
- Deferred complexity
- No speculative graph
Context
Dependency graphs are familiar in project-management software. A team declares that task B depends on task A, the product draws an edge, and a timeline attempts to predict how delay will move through the plan.
Adding that model to Aura 4 was attractive because it looked like a complete answer to blocked work. It was also a large commitment: dependency types, graph editing, scheduling semantics, visualization, permissions, migration rules, and ongoing maintenance by users.
The problem with declared certainty
A dependency view is useful only when its edges are complete and current. Missing relationships hide risk. Stale relationships create false warnings. Both cases make a precise-looking graph less trustworthy than the work it claims to explain.
The graph records what somebody predicted before work started. Aura 4's product problem was more immediate: when work stops, who is waiting, who can respond, what is unresolved, and when did the blockage clear?
Separating the problem from the feature
Dependency edge
Task B waits on task A. The relationship is declared in advance and must remain maintained as the plan changes.
Aura 4 Loop
A specific task is blocked now. The record names the person waiting, the person who can act, the reason, and the resolution state.
The Loop captures an operational fact. It does not require the team to model every possible relationship before that relationship affects delivery.
The decision
I kept Loops as the first-class blocker model and did not add a general dependency graph. The system records actual interruptions with explicit ownership, then uses those records for stale-loop signals, handovers, and follow-up.
Observe the blockage → assign responsibility → record resolution
This keeps the data close to the event the team experienced. It also makes each record actionable instead of turning it into another line on a planning diagram.
Why inference was deferred
The repository research considered learning structural dependencies from repeated blocker history. That direction could reveal relationships teams consistently encounter without asking them to maintain a graph by hand.
The idea was deliberately postponed. Aura 4's Loop corpus was too young to test whether the inferred relationships would be accurate or useful. Building inference first would create technical sophistication without enough evidence to evaluate it.
The re-evaluation gate is data, not enthusiasm: revisit the idea when multiple real teams have accumulated a meaningful history of closed blocker Loops with clear ownership.
Trade-offs
Without declared dependencies, Aura 4 provides less advance timeline forecasting. Teams that need formal critical-path planning may prefer a dedicated planning product.
In return, Aura 4 avoids dependency maintenance, graph visualization, scheduling rules, and a false sense of completeness. The product stays focused on resolving the blockers that are affecting work now.
Engineering principle
Model the operational truth before automating the predicted structure.
What this demonstrates
- Separate the user's blocked-work problem from a familiar feature request.
- Question an abstraction that depends on perfect manual maintenance.
- Prefer observed domain records over speculative relationships.
- Use data maturity as an architecture gate for later automation.
- Accept a narrower product when it produces more trustworthy information.
M.ABU SALH
VI
Templates
N°06 / 07
Ship the
portfolio first.
A polished developer portfolio template with the structure, motion, and visual weight already handled. Replace the content, tune the palette, and launch without rebuilding the whole stage.
New release
01
06
Portfolio Pro
$29
Editorial portfolio kit for engineers who need more than a resume page.
One-page storytelling, project tiles, responsive sections, smooth view transitions, and a ready-to-edit static codebase.
- 01 Hero, work, experience, contact sections
- 02 Mobile-first responsive composition
- 03 Editable colors, images, and project data
M.ABU SALH
M. Abu Salh
Full‑stack engineering for ambitious ideas.
From architecture to launch, I build products that ship, scale, and feel right.