Continuous integration
Changes are built and checked automatically, so problems are caught before they reach anyone who depends on the software.
Evidence: Public Go library runs CI on every change.
Evidence and proof points
Proof that PickTech builds serious software.See beyond the simulation. Explore the real code.
Anyone can claim to be a good engineer. This page points at public work you can open and read for yourself: tested libraries, production observability, policy-as-code, and controlled AI design. Each example explains what it shows in plain English, then links to the technical detail.
How to read this page
- Non-technical? Read the delivery habits and the "Why it matters" lines.
- Technical? Follow the repository links and the signal tags on each example.
- Deciding what to do next? Each example links to the services and situations it relates to.
Delivery habits
The engineering habits behind the work.
These are the practical habits that make software dependable. Every one is backed by public evidence further down the page.
Serious testing
Tests, coverage reporting, and mutation testing back up the claim that the code actually works and keeps working.
Evidence: Mutation testing and coverage reporting on go-collections.
Observability
Systems are built so teams can see what is happening in production: metrics, traces, logs, and dashboards, not guesswork.
Evidence: OpenTelemetry examples for both Java and Node.
Kubernetes
Infrastructure and monitoring are managed as repeatable configuration, not hand-cranked one-off setups.
Evidence: Self-hosted Kubernetes monitoring stack managed with Kustomize.
Policy as code (OPA)
Governance rules are written down and enforced automatically, with practical paths for teams that cannot change everything overnight.
Evidence: OPA Gatekeeper enforcement with loose and strict rollout scenarios.
FinOps
Cloud cost is connected to the people, systems, and decisions behind it, so spend can be explained and controlled.
Evidence: FinOps report-response workflow design.
AI workflow design
AI is applied to narrow, well-bounded problems with clear controls, audit trails, and least-privilege access.
Evidence: Controlled AI FinOps workflow whitepaper with guardrails and IAM design.
Documentation habits
Work is documented so technical and non-technical people can review decisions, usage, and trade-offs later.
Evidence: Package docs, runnable examples, and review-ready whitepapers.
Commercial experience
Contract work for brands where software quality matters.
PickTech can talk plainly about the kinds of systems, technical environments, and delivery pressure involved. The detail is written in words rather than client logos, because the point is not borrowed prestige; it is evidence of where this experience has been applied.
Public examples
Work you can open and read for yourself.
These are real public repositories, not marketing mock-ups. Each card explains what it is, why it matters, and where it connects to the services PickTech offers.
Tests, CI, and documentation
go-collectionsA maintained, tested open-source library
The strongest public engineering proof point: a substantial Go library built with the boring details done properly.
What it is
A type-safe Go collections library using generics, with thread-safe variants for maps, sets, lists, deques, heaps, and LRU caches, plus utilities for concurrency, streaming, statistics, and machine-learning metrics. It is maintained with CI, mutation testing, coverage reporting, generated benchmark reports, runnable examples, and package-level documentation.
Why it matters
It shows the habits that make software dependable: careful API design, tests you can trust, benchmarks, and documentation. That is the same discipline PickTech brings to client work, so what gets built is easier to maintain long after delivery.
Technical signals
Go generics
CI
Mutation testing
Coverage reporting
Benchmarks
Runnable examples
Package docs
Related services
Kubernetes and observability
Kubernetes-Monitoring-ExampleProduction monitoring managed as code
A self-hosted Kubernetes monitoring stack, configured so the whole setup is repeatable.
What it is
A monitoring stack built with Kustomize covering Prometheus, Grafana, kube-state-metrics, and cAdvisor, with dashboard ConfigMaps and datasource provisioning defined as configuration rather than manual clicks.
Why it matters
Production visibility is treated as part of the build, not an afterthought. Teams can see what is happening after deployment, and the setup can be recreated reliably instead of living in one person's head.
Technical signals
Kubernetes
Kustomize
Prometheus
Grafana
kube-state-metrics
cAdvisor
Related services
Policy as code and governance
kubernetes-opa-exampleGovernance turned into enforced, practical rules
OPA Gatekeeper enforcement with realistic rollout paths for teams that cannot change everything at once.
What it is
OPA Gatekeeper policy requiring an assetUuid label on Kubernetes deployments, with loose and strict enforcement scenarios, time-based exclusions, Kustomize configuration, and validation scripts.
Why it matters
Governance is easier when it is explicit, automated, and gradual. This shows how policy becomes repeatable engineering practice, including sensible on-ramps for legacy systems that cannot comply overnight.
Technical signals
OPA Gatekeeper
Kubernetes admission control
Policy as code
Kustomize
Gradual rollout
Related services
Observability
SpringBootOtelExampleEnd-to-end observability for a Java service
A Java/Spring Boot service instrumented so its behaviour is visible across code, metrics, traces, and logs.
What it is
A Spring Boot service instrumented with OpenTelemetry, Micrometer, and Actuator, exporting to Prometheus, Grafana, Tempo, and Loki, with customer context propagation, distributed tracing, JVM and system metrics, dashboards, and tests.
Why it matters
Observability is more than adding a dashboard. It means designing useful signals into a system: request flow, customer context, latency, errors, and downstream calls, so problems can be understood under real load.
Technical signals
OpenTelemetry
Micrometer
Distributed tracing
Prometheus
Grafana
Tempo
Loki
Related services
Observability across stacks
ExpressOtelExampleThe same operational discipline in Node
A TypeScript/Node instrumentation library proving the approach is not tied to one language.
What it is
A TypeScript Express OpenTelemetry instrumentation library with tracing, metrics, customer ID middleware, Axios instrumentation, Grafana, Prometheus, and Tempo support, strict TypeScript, dual module builds, docs, examples, and tests.
Why it matters
Whether a service is Java or Node, the engineering questions are the same: can we trace it, measure it, test it, deploy it, and understand it under load? PickTech keeps the same standards across different stacks.
Technical signals
TypeScript
Node / Express
OpenTelemetry
Strict TypeScript
Dual module builds
Tests
Related services
AI workflow design and FinOps
finops-ai-report-response-portal-whitepaperControlled, auditable AI in a locked-down environment
A detailed whitepaper for an AI-assisted FinOps workflow inside a controlled AWS environment.
What it is
A whitepaper and renderer for an AI-assisted workflow responding to enterprise FinOps report items, covering SSO, case-specific chat, Amazon Bedrock, controlled backend writes, S3 exports, guardrails, security architecture, IAM, networking, a risk register, delivery plan, and diagrams.
Why it matters
AI can be useful, but only when the boundaries are clear. This shows deliberately practical AI: narrow use cases, clear audit trails, validated backend actions, least-privilege access, and no vague autonomy promises.
Technical signals
Amazon Bedrock
Guardrails
IAM / least privilege
Audit trails
Security architecture
Risk register
Related services
Where to go next
Match the proof to your situation.
If any of the work above feels close to your situation, these pages show practical ways to engage PickTech.
Build something new
Turn an idea into a real, tested first version without wasting budget finding out what works.
MVP, POC, and internal tools →Senior engineering support
Add experienced, hands-on delivery, review, and observability habits without a permanent hire.
Outside IR35 support →Technical risk review
Get a plain-English view of technical risk before you commit money, reputation, or time.
Technical due diligence →