• Networks & Linux since 2011
  • Web work since 2014
  • Worked with teams worldwide

Seyed Reza Bazyar

I start at the root of a problem, then build only what it needs.

At sixteen, I set up home networks, learned hardware, installed Linux, and wrote small scripts by hand. I moved into PHP web work in 2014, building apps, APIs, and database-backed features. I still read the code, query plans, and logs myself. I build AI agents and bots to automate repetitive work and reduce the time and cost it takes.

Outside of code, I love books.

Networks & Linux
Since 2011
PHP web work
Since 2014
Everyday tools
Laravel · Nuxt · Elasticsearch · Python
  1. 2011Networks, Linux, and hand-written code
  2. 2014PHP and web systems
  3. NowAgents and automation

workbench:~

Live terminal
Terminal response

I started with home networks, hardware, and Linux at sixteen. I wrote small scripts by hand, then moved into PHP web work in 2014.

Skills & tools

The parts of a web system I work with day to day.

Backend & APIs

Application logic and integrations

  • PHP 8
  • Laravel
  • Python
  • REST & JWT

Data & search

Storage, read paths, and retrieval

  • MySQL / PostgreSQL
  • MongoDB
  • Elasticsearch
  • Redis

Infrastructure

The services and networks beneath the app

  • Linux & systemd
  • Nginx & Apache
  • Docker
  • Networks, DNS & TLS

Web & frontend

Rendered pages and browser-side code

  • Nuxt (SSR)
  • TypeScript
  • Tailwind CSS
  • WordPress & WooCommerce

AI & automation

Repeatable work with human review

  • Cooperating agents
  • LLM pipelines
  • Telegram bot
  • Data collection & processing

Delivery & operations

Changes that teams can follow

  • Git & CI
  • Docs & task writing
  • Monitoring & alerts
  • Security review

Past work

A few kinds of engineering problems I have worked through.

  1. Search

    Multilingual search and retrieval

    Persian and multilingual search returned uneven results, and the index lagged behind its source. I normalized text and ranking, then kept Elasticsearch aligned with the primary database.

    • Elasticsearch
    • MySQL / PostgreSQL
  2. Data

    Read models for database-backed systems

    The relational database served every read pattern. I split out a read model, used keyset pagination, and tuned indexes from query plans.

    • MySQL / PostgreSQL
    • MongoDB
    • Redis
  3. Performance

    Speed and resource cost

    Hot paths raised latency and resource use. I traced the bottleneck, separated cache from queues, set service budgets, and used Octane where it fit.

    • Laravel
    • Redis
    • Linux & systemd
  4. Reliability

    Health checks, alerts, and recovery

    Noisy alerts and risky deploys slowed recovery. I added a light health endpoint, central alerts, rollback steps, and blame-free postmortems.

    • Linux & systemd
    • Monitoring & alerts
    • Git & CI
  5. Networks

    Edge behavior and international routes

    Traffic varied by route and crawler. I tuned proxy rules and rate limits, measured CDN effects, and traced international issues through MTU and PMTUD.

    • Nginx & Apache
    • Networks, DNS & TLS
    • Monitoring & alerts
  6. Security

    API access and data exposure

    API responses and downloads had unclear access boundaries. I reviewed data exposure, used signed links and per-user checks, and documented vulnerability disclosure.

    • REST & JWT
    • Security review
  7. Data work

    Repeatable collection and processing

    Public-source data arrived in mixed formats. I used rate-limited crawlers and queues, normalized records into SQL, and made the pipeline repeatable.

    • Python
    • Data collection & processing
    • Redis
  8. Agents

    Agent workflows with review points

    Agent workflows needed cost and approval boundaries. I compared batch and live model runs, used multi-agent steps where they fit, and kept code review and human approval in the loop.

    • Cooperating agents
    • LLM pipelines
    • Git & CI
    • Monitoring & alerts

How I work

Small steps, written down as we go.

Logs, query plans, and curl first; then a small, reversible change, documented in the same commit.

  1. Check the evidence first

    Read the logs, query plan, or request before changing code.

  2. Keep changes reviewable

    Make a focused change that a teammate can measure and roll back.

  3. Write the task and decision down

    Put the task and its reason in writing; keep the notes with the commit.

  4. Treat cost as a requirement

    Choose the smallest tool that meets the need, then compare its running cost.

  5. Automate repeat work; keep human approval

    Agents can handle repeatable steps. People keep the judgment and sign-off.

  6. Leave a usable handoff

    Include a runbook, monitoring, alerts, and notes the team can use without me.

Problems I work on

A few examples of where I can help.

If

Your team repeats the same slow task

I do

I map the steps, automate the repeatable work, and keep review and traceability in place.

If

Search or data is hard to trust

I do

I shape the search index, read model, or processing pipeline around how the data is used.

If

A backend or API is getting in the way

I do

I trace the request, then work on the Laravel app, queue, or integration that needs attention.

If

The system is slow or costly to run

I do

I find the measured bottleneck and reduce wasted work or resource use.

If

An unreliable system keeps you up

I do

I work through reliability, monitoring, recovery, and access controls.

If

A WordPress store needs custom work

I do

I build the plugin or automation missing from the publishing and commerce flow.

If your problem isn’t on this list, tell me what’s going on.

Working with a team

A clear scope and a handoff the team can keep using.

How we get started

  1. Describe the problem

    Tell me the outcome, constraints, and budget you have in mind.

  2. Get written options

    I’ll outline two or three ways forward, with trade-offs and costs.

  3. Start with a small working version

    Build and review a runnable slice before expanding the scope.

  4. Hand over the operation

    Leave documentation, monitoring, alerts, and next steps with the team.

Ways to work together

  • Architecture and code review
  • Stabilization and incident work
  • Agent and automation sprint
  • Cost and performance review
  • Build from idea to production
  • Work inside your team

What a handoff can include

  • Written decisions and documentation
  • Monitoring and alerts
  • A system cost report
  • A list of next steps

Questions teams often ask

What kinds of problems do you take on?

My work spans backends and APIs, search and data, performance and cost, reliability and security, and task automation. If your issue is not on that list, describe it in the form.

Where do AI agents help, and where do they not?

They fit repeatable work with clear inputs and results someone can review. Decisions with real consequences and final approval stay with a person. If checking the output costs more than doing the task, an agent is the wrong fit.

How do you keep costs down?

Start with logs, query plans, and resource use. Fix the measured bottleneck, choose the smallest tool that fits, and check the result against its running cost.

Can you work with our existing team?

Yes. We can agree on the task format, review process, access, and handoff before work begins.

How do you hand over code and documentation?

Changes stay reviewable in Git. The handoff can include runbooks, monitoring, alerts, written decisions, and next steps.

How do we start?

Send the problem, the outcome you need, constraints, and a budget range. I’ll reply with written options and the trade-offs to discuss.

Tell me what you’re working on

I work remotely with teams worldwide. Send the goal, constraints, current behavior, and budget range; we can start with a written assessment.

Working arrangement
Remote · worldwide

This prepares an email draft in your mail app. Review and send it there.