Agentic software developer

I'm Ridoy, a software developer with 6+ years of experience. I build SaaS platforms, backends, interfaces and cloud setups, so you get software that works on day one and keeps working.

See my workTalk about your project
  • ✓One developer for the whole stack — backend, frontend and cloud
  • ✓Clear architecture and contracts before the build starts
  • ✓Shipped, monitored and maintained — not thrown over the wall
Ridoy Sheikh

Cloud & DevOps

AWS · Docker · Kubernetes

Backend

FastAPI · Go · PostgreSQL

Youbringtheproblem.Itakeitfromideatoproduction—andkeepitrunning.

What I can do for you

Pick one, or combine them. The same habits run through all of it: clear contracts, small services with clear jobs, and software built to be operated.

  • Architecture & SaaS platforms

    I design the services, data model and APIs, then build them: multi-tenant, with billing, roles, background jobs and live updates.

    See it in

    AnalyzeAlphaSovereignTerminalWorthLedgerCUT2STYLE (C2S)

  • Libraries & developer tools

    When your team keeps solving the same problem, I build the library or tool that ends it — and document it so the next person can use it.

    See it in

    SynAlchemySynTextEditorAlphaChartSynUI

  • Cloud & DevOps

    I take it live and keep it running: Docker, AWS, repeatable deploys, monitoring and backups — on the cloud, on Kubernetes or on your own servers.

    See it in

    SynCloudSynMailAnalyzeAlpha

  • AI features

    Document extraction, assistants and search over your own data — with output checked against a schema, a person in the loop where it matters, and assistants that can only use the tools you allow.

    See it in

    CalendarizeSynlorCommerzaSynTest

My work

Open any project for the story, the architecture and the stack behind it.

Software development lifecycle

Seven phases, one loop. Each one ends with something you can see, use or keep — and Improve feeds straight back into Discover.

  1. 01 / 07

    Discover — Start with your problem

    Before any code, I make sure we're solving the right problem: who it's for, what success looks like, and what is deliberately out of scope.

    What I do

    • · Talk through your goals, users and constraints
    • · Surface the risks and unknowns early
    • · Break the idea into milestones you can ship

    What you get

    • · A scoped plan with milestones
    • · An honest estimate and the trade-offs behind it
    • · A clear "not now" list
    • Written plan
    • User stories
    • Risk list

  2. 02 / 07

    Design — Architecture and contracts first

    I design the system on paper first: how it splits into services, what data it holds, and how the parts talk to each other.

    What I do

    • · Draw the service boundaries and the data model
    • · Specify every API as a contract (OpenAPI)
    • · Sketch the key user flows

    What you get

    • · An architecture diagram
    • · An API specification your team can read
    • · A data model and migration plan
    • OpenAPI
    • PostgreSQL
    • Pydantic · Zod

  3. 03 / 07

    Build — Small steps you can see

    I build in short increments and show working software early and often, so you steer with real things instead of slides.

    What I do

    • · Write typed code in your repo, reviewed before it merges
    • · AI-assisted development, with every change reviewed
    • · Send frequent demos and written updates

    What you get

    • · Working software every iteration
    • · Code you own, in your repository
    • · Documentation written as I go
    • Python · FastAPI
    • Go
    • TypeScript · Next.js
    • Git

  4. 04 / 07

    Test — Proof it works

    Tests are part of the build, not an afterthought. They run on every change, so a fix in one place can't quietly break another.

    What I do

    • · Unit and integration tests where they matter
    • · Contract tests against your API spec
    • · Automated checks on every push

    What you get

    • · A test suite that runs in CI
    • · Regression reports, not just pass or fail
    • · Confidence to change things later
    • pytest
    • Vitest
    • SynTest
    • GitHub Actions

  5. 05 / 07

    Release — Boring, repeatable deploys

    Shipping should be a non-event. I package the app once and release it the same way every time — to AWS, a Kubernetes cluster or your own servers.

    What I do

    • · Containerise with Docker, one image per service
    • · Keep configuration in the environment, not the code
    • · Run migrations as separate, repeatable steps

    What you get

    • · One-command deploys and a way back
    • · A staging setup that mirrors production
    • · Versioned releases with notes
    • Docker
    • AWS
    • Kubernetes
    • Dokploy
    • GitHub Actions

  6. 06 / 07

    Operate — Running it is part of the job

    I set up monitoring, logs and backups before launch, so problems show up on a dashboard instead of in a customer's email.

    What I do

    • · Wire in metrics, logs and alerts
    • · Set up backups with a tested way back
    • · Keep dependencies and security patches current

    What you get

    • · Visibility into health and errors
    • · A recovery plan you can actually read
    • · The option to keep me on to run it
    • Metrics & logs
    • Alerts
    • Backups

  7. 07 / 07

    Improve — Learn from real use

    After launch the real work starts: seeing how people use it, fixing what hurts and building what matters most.

    What I do

    • · Review usage and performance
    • · Pay down technical debt in small steps
    • · Plan the next releases with you

    What you get

    • · A living roadmap
    • · Faster, steadier releases
    • · Docs and a clean handover for your team
    • Analytics
    • Profiling
    • Roadmap

Cloud, containers & delivery

AWS, Docker, Kubernetes or your own servers — I pick what fits your product and your team, and set it up so it runs the same way every time.

  • AWS

    AWS

    Cloud services that scale with you.

    • Lambda for APIs that scale to zero
    • DynamoDB and S3 for state and files
    • Textract for reading scanned documents
    • Lambda
    • DynamoDB
    • S3
    • Textract

    See it in

    AnalyzeAlphaCommerzaCUT2STYLE (C2S)Synlor
  • Dk

    Docker & Compose

    The same container from laptop to production.

    • One image per service, multi-stage builds
    • Compose for local work and single-server deploys
    • Images published to a registry on every release
    • Docker
    • Docker Compose
    • GHCR

    See it in

    AnalyzeAlphaCommerzaSovereignTerminalSynlor
  • K8

    Kubernetes

    When your scale or team calls for a cluster.

    • Deployments, ingress, secrets and rolling updates
    • Right-sized: lean clusters rather than heavy platforms
    • And an honest answer when you don't need one
    • Kubernetes
    • Ingress
    • Rolling updates
  • SH

    Self-hosted platforms

    Your own servers, without the toil.

    • Dokploy and Compose on plain Linux machines
    • Or SynCloud, my own self-hosted cloud, for fleets
    • Private networking, HTTPS and backups included
    • Dokploy
    • SynCloud
    • WireGuard
    • Traefik

    See it in

    SynCloudSynlorSynMail
  • CI

    CI/CD & releases

    Every change tested, every release repeatable.

    • Tests and checks on every push
    • Versioned releases with checksums
    • One-command deploys with a way back
    • GitHub Actions
    • GHCR
    • Release checksums

    See it in

    SynMailSynAlchemySynTest
  • DB

    Data layer

    The right store for each job.

    • PostgreSQL as the default, with pgvector for search
    • Redis or Valkey for queues, caches and live updates
    • S3-compatible object storage for files
    • PostgreSQL
    • pgvector
    • Redis / Valkey
    • S3
    • SQLite

    See it in

    CommerzaSovereignTerminalWorthLedgerAnalyzeAlpha
  • Ed

    Edge, network & security

    Fast at the edge, locked down underneath.

    • Go services at the edge for custom domains and tenants
    • mTLS between services, WireGuard between servers
    • Signed tokens, scoped access and audit logs
    • Traefik
    • mTLS
    • WireGuard
    • JWT · JWKS

    See it in

    SynCloudAnalyzeAlphaCommerza
  • Ob

    Monitoring & backups

    You hear about problems from a dashboard first.

    • Metrics, logs and alerts in one place
    • Backups with point-in-time restore
    • A recovery plan written down, not remembered
    • Metrics
    • Logs
    • Alerts
    • PITR backups

    See it in

    SynCloud

The twelve-factor app

The standard playbook for software that runs in the cloud: it deploys the same everywhere and scales without surprises. Scroll through what each factor means for you.

  1. Factor 01

    Codebase

    One codebase per service, tracked in Git and deployed many times.

    For you: A single source of truth and a clean history to audit.

    Commerza runs as seven services, each in its own repository.

  2. Factor 02

    Dependencies

    Every dependency is declared and locked — nothing relies on what happens to be installed.

    For you: Builds that reproduce on any machine, including yours.

    Lockfiles ship with the projects: uv, pnpm, npm and go.sum.

  3. Factor 03

    Config

    Settings live in the environment, never in the code.

    For you: The same build runs in staging and production, and secrets stay out of Git.

    Services document their settings in an .env.example.

  4. Factor 04

    Backing services

    Databases, queues and storage are attached resources, addressed by URL.

    For you: Swap a local Postgres for a managed one by changing a setting, not the code.

    SynMail takes Postgres and S3 purely from its environment.

  5. Factor 05

    Build, release, run

    Build once, combine with config at release, run the result.

    For you: Versioned releases you can roll forward or back.

    SynMail publishes its API and mail-server images to a registry on every tag.

  6. Factor 06

    Processes

    Processes are stateless; anything that must last lives in a backing service.

    For you: Scale by adding instances. Restarts are harmless.

    SynMail keeps DKIM keys and certificates on S3, not on local disk.

  7. Factor 07

    Port binding

    Each service exposes itself on a port — no app-server magic around it.

    For you: It runs anywhere a container runs.

    AnalyzeAlpha's accounts, finance, filings and socket services each bind their own port.

  8. Factor 08

    Concurrency

    Scale out by process type: web, worker and scheduler run separately.

    For you: Heavy background work never slows down your users.

    Taskiq workers run beside the API in CUT2STYLE, Synlor and Commerza.

  9. Factor 09

    Disposability

    Fast start, clean stop: processes can be started or killed at any moment.

    For you: Quick deploys, quick recovery, easy autoscaling.

    SynCloud and SynTest ship as single static binaries with no runtime to boot.

  10. Factor 10

    Dev/prod parity

    Development uses the same kind of Postgres and Redis as production.

    For you: Fewer "works on my machine" surprises at launch.

    Commerza's local stack brings up Postgres and Redis in Compose.

  11. Factor 11

    Logs

    Logs are a stream of events, collected and searchable in one place.

    For you: When something breaks, the answer is one search away.

    SynCloud ships its own log and metrics stack.

  12. Factor 12

    Admin processes

    One-off tasks like migrations and seeds run as one-off, repeatable commands.

    For you: Schema changes are scripted and reviewable, never hand-typed in production.

    Migrations run as a separate step in SynMail, Commerza and SynAlchemy.

Libraries I maintain

A database toolkit, a rich-text editor, a UI builder and financial charts. They run inside my own products today, and they're versioned and documented like anything I'd hand to you.

Skills in use

Pick an area. Each tool links to the projects where I've used it.

Programming Languages

The languages I write every day.

AI integration

Extraction, assistants and search over your own documents — built with validation and human review where it matters.

  • Extraction you can trust

    Turn documents, screenshots and emails into structured data. Every result is validated against a schema and reviewed by a person before it's saved.

    See the project →

  • Assistants with limits

    Support and workspace assistants that answer through read-only tools, stay quiet when they're unsure, and hand the conversation to a person.

    See the project →

  • Answers with sources

    Ask questions of your PDFs and scanned documents and get answers with citations you can click and verify.

    See it on GitHub ↗

  • Ready for AI agents

    Give agents and integrations scoped API access without ever sharing a user's session.

    See the project →

  • Tests that find edge cases

    Let a model propose the awkward inputs, then compare every run with the last so you see exactly what regressed.

    See the project →

Open source

The libraries and tools below are public. Read the code, the commit history and the releases — and see how I work day to day.

github.com/ridoysheikh

My GitHub activity, last 12 months

1,563 contributions, including private client work

NovDecJanFebMarAprMayJunJulAugSepOctNov
Less More

Public repositories

  • syncloudPublic

    Your own cloud on your own servers: deploy containers, managed Postgres and Valkey across a fleet of Linux machines.

    GoRead more →
  • synalchemyPublic

    Async multi-database toolkit for SQLAlchemy 2.x: per-model routing, automatic engines and async migrations.

    PythonRead more →
  • SynTextEditorPublic

    A rich text editor for React and Next.js whose document is data, not HTML (@syntext/react).

    TypeScriptRead more →
  • synui-cdnPublic

    Public CDN build of the SynUI renderer, served by jsDelivr.

    JavaScriptRead more →
  • syntestPublic

    Tests a live API against its OpenAPI spec and reports what broke since the last run.

    GoRead more →
  • OCRRAGPublic

    PDF question answering with AWS Textract OCR, pgvector search and verifiable citations.

    Python

Contact

Let's talk about your project.

Tell me what you're building and where it hurts. I'll reply with how I'd approach it, what it would take, and what I'd leave out.

Email meMessage on LinkedIn