diff --git a/.github/workflows/validate.yml b/.github/workflows/validate.yml new file mode 100644 index 0000000..d3e2e6e --- /dev/null +++ b/.github/workflows/validate.yml @@ -0,0 +1,35 @@ +name: Validate Pull Request + +on: + pull_request: + branches: + - main + +permissions: + contents: read + +jobs: + build: + name: Build Astro site + runs-on: ubuntu-latest + + steps: + - name: Checkout + uses: actions/checkout@v5 + + - name: Setup pnpm + uses: pnpm/action-setup@v4 + with: + version: 10 + + - name: Setup Node.js + uses: actions/setup-node@v5 + with: + node-version: 22 + cache: pnpm + + - name: Install dependencies + run: pnpm install --frozen-lockfile + + - name: Build + run: pnpm build diff --git a/src/components/Welcome.astro b/src/components/Welcome.astro index 6652a75..89fce1b 100644 --- a/src/components/Welcome.astro +++ b/src/components/Welcome.astro @@ -1,210 +1,133 @@ ---- -import astroLogo from '../assets/astro.svg'; -import background from '../assets/background.svg'; ---- - -
- -
-
- Astro Homepage -

- To get started, open the
src/pages
directory in your project. -

- -
-
- - - -

What's New in Astro 7.0?

-

- Rust-powered compiler, advanced routing, AI agent support, and more! Click to explore Astro - 7.0's new features. -

-
-
+
+ + +
+

Senior Backend Engineer · PHP/Laravel · Go

+

I build backend systems that can be understood, tested and operated with confidence.

+

+ Ten years of experience building SaaS platforms, payment systems and distributed services. + I enjoy complex problems, explicit boundaries and trade-offs that hold up in production. +

+ +
+ +
+
10 yearsof software development
+
Go + PHPproduction backend
+
Paymentsintegrations and reliability
+
ICownership without management
+
+ +
+
+

Selected work

+

Projects that show how I think.

+
+ +
+ + +
+
02PHP · Laravel · Payments
+

LaraWebhook

+

+ A Laravel package built from scratch to process multi-service webhooks with signatures, + idempotency, retries, replay, audit trails and configurable payload storage. +

+
  • Unit, functional and architecture tests
  • CI, documentation and static analysis
  • Built independently in approximately 80 hours
+ Read the case study ↗ +
+
+
+ +
+

What I am looking for

An individual contributor backend role in a team that believes in its product.

+
+
Target

Senior Backend Engineer or backend-focused Senior Software Engineer, with real technical ownership.

+
Environment

A useful product, B2B SaaS, fintech, security, compliance or critical systems. Genuine remote work from Strasbourg.

+
Not looking for

People management, permanent coordination, feature factories or primarily frontend roles.

+
+
+ +
+

How I work

Complexity deserves structure. Not ceremony.

+
+
Understand before abstracting

I look for the real problem, invariants and boundaries before choosing an architecture.

+
Make failure testable

Retries, timeouts, concurrency and inconsistencies should not remain impossible-to-reproduce accidents.

+
Stay hands-on

I take ownership of complex topics, help others become more autonomous and stay close to the code.

+
+
+ + +
diff --git a/src/layouts/Layout.astro b/src/layouts/Layout.astro index 21bfe59..aa79869 100644 --- a/src/layouts/Layout.astro +++ b/src/layouts/Layout.astro @@ -1,23 +1,40 @@ +--- +interface Props { + title?: string; + description?: string; +} + +const { + title = 'Proxynth — Senior Backend Engineer', + description = 'Senior Backend Engineer focused on complex systems, payments and reliability.', +} = Astro.props; +--- + - - - - - - - Astro Basics - - - - + + + + + + {title} + + + + - diff --git a/src/pages/index.astro b/src/pages/index.astro index c04f360..652db93 100644 --- a/src/pages/index.astro +++ b/src/pages/index.astro @@ -1,11 +1,11 @@ --- import Welcome from '../components/Welcome.astro'; import Layout from '../layouts/Layout.astro'; - -// Welcome to Astro! Wondering what to do next? Check out the Astro documentation at https://docs.astro.build -// Don't want to use any of this? Delete everything in this file, the `assets`, `components`, and `layouts` directories, and start fresh. --- - - + + diff --git a/src/pages/projects/larawebhook.astro b/src/pages/projects/larawebhook.astro new file mode 100644 index 0000000..e6b0ae8 --- /dev/null +++ b/src/pages/projects/larawebhook.astro @@ -0,0 +1,29 @@ +--- +import Layout from '../../layouts/Layout.astro'; +--- + + +
+ ← Back to the portfolio +

Open source project · PHP · Laravel

+

LaraWebhook

+

A Laravel package for treating webhooks as messages that may be delayed, duplicated or replayed.

+

The problem

Webhook integrations must handle signatures, retries, duplicates, transient failures and the need to investigate what actually happened.

+

What it provides

  • multi-service signature validation;
  • idempotency protected against concurrent races;
  • synchronous and asynchronous retries;
  • replay and an audit trail separated from deduplication;
  • none, redacted or full payload storage;
  • dashboard, API, notifications and documentation.
+

What the project demonstrates

The package was designed and implemented independently in approximately 80 hours, with unit, functional and architecture tests, PHPStan, Pint, Pest, CI and release automation.

It is a personal technical demonstration with no known external adoption.

View the GitHub repository ↗
+
+
+ + diff --git a/src/pages/projects/payment-sandbox.astro b/src/pages/projects/payment-sandbox.astro new file mode 100644 index 0000000..2d64899 --- /dev/null +++ b/src/pages/projects/payment-sandbox.astro @@ -0,0 +1,30 @@ +--- +import Layout from '../../layouts/Layout.astro'; +--- + + +
+ ← Back to the portfolio +

Open source project · Go · Payments

+

Payment Sandbox

+

Testing a payment integration means more than checking HTTP status codes.

+

The problem

A payment may succeed while the HTTP response is lost. A webhook may arrive twice, late or out of order. Two concurrent capture requests may race. These situations are difficult to reproduce with a traditional HTTP mock.

+

The approach

Payment Sandbox models payment workflows and the asynchronous behaviours around them. Scenarios are deterministic, observable and reproducible, making it possible to test integrations without depending on a real provider.

  • lost responses and retries with idempotency keys;
  • delayed, duplicated, invalid or out-of-order webhooks;
  • concurrent capture and refund races;
  • temporarily inconsistent states and deterministic replay.
+

Architecture choices

The project uses a modular monolith, domain-driven design and targeted hexagonal architecture. The goal is not to distribute the system artificially, but to isolate boundaries that provide real value: domain, persistence, clock, randomness, durable jobs and HTTP delivery.

+

Project status

The project is currently in an early design and implementation phase. Public contracts and the scenario format are not stable yet.

View the GitHub repository ↗
+
+
+ +