Most "implemented" bullets read like a closed Jira ticket, not an engineering achievement. Half of software engineer resumes use the word. It tells a recruiter you touched something without saying what happened because of it. No scale, no outcome, no stake. It's the resume version of "did work," and no screener files that away.

What weak "implemented" bullets look like

Four real-pattern offenders — and exactly why each one collapses under scrutiny.

"Implemented new authentication service." Zero context: what broke before, who uses it now, what the failure rate was. This tells a reviewer nothing about scope or consequence. It could mean one service used by three internal engineers or a rebuild touching millions of sessions.

"Implemented API rate limiting across services." No scale attached. Protecting 50 internal endpoints reads completely differently than protecting 5,000 external customer-facing ones. The missing number makes the bullet impossible to evaluate against another candidate's bullet.

"Implemented automated testing framework." Process described, outcome missing. What was coverage before? What regressions has it caught? Without those numbers, this bullet is decoration — a line that says "I did a good-practice thing" without proving the practice worked.

"Implemented microservices migration." Sounds consequential, delivers nothing. Migration of how many services? From what? Over what timeline? "Microservices" is doing the heavy lifting while the verb sits there describing nothing specific to you.

Stronger swaps — 15 synonyms

Synonym When it fits Resume bullet
Engineered You designed the solution, not just executed a spec Engineered request-deduplication layer that cut duplicate API calls by 38%, saving $14K/month in downstream service costs
Deployed Getting something live was the actual work Deployed gRPC-based order service to prod, reducing p99 latency from 420ms to 110ms across 2.1M daily requests
Shipped Startup or product context; users received a feature Shipped real-time push notification service to 340K iOS users with 99.4% delivery rate in the first 30 days
Architected You made system-level design decisions Architected event-driven pipeline on Kafka processing 180K events/sec with sub-200ms end-to-end latency
Built Something existed after that didn't before Built internal SDK for auth token refresh, adopted by 6 engineering teams and eliminating 4,200 lines of duplicate code
Integrated You connected two systems or APIs Integrated Stripe payment API with legacy billing service, dropping checkout error rate from 3.1% to 0.4%
Rolled out Gradual or staged release to users or teams Rolled out feature-flag system to 12 services, enabling zero-downtime releases for 90% of production deploys
Introduced You brought a practice or tool new to the org Introduced load shedding at the API gateway, preventing 3 P1 incidents during peak traffic spikes of 85K req/min
Launched Something went live externally for the first time Launched public GraphQL API for 1,800 developer accounts, hitting 99.97% uptime across the first quarter
Overhauled You replaced something broken Overhauled logging pipeline from custom sidecar to OpenTelemetry, reducing mean-time-to-detect from 18 min to 4 min
Refactored You rewrote for quality, performance, or maintainability Refactored monolithic user service into 3 domain services, cutting average deploy time from 22 min to 6 min
Migrated You moved from one platform or system to another Migrated 6TB PostgreSQL database from on-prem to RDS with zero data loss inside a 4-hour maintenance window
Automated You eliminated a manual process Automated cert rotation for 140 internal services, cutting ops ticket volume by 60% and removing recurring on-call toil
Optimized You improved performance of something that already existed Optimized N+1 query pattern in orders API, reducing DB calls by 71% and dropping average response time by 190ms
Established You set up infrastructure or process from scratch Established CI/CD pipeline (GitHub Actions + ArgoCD) for 8 microservices, enabling the team to ship three times per week

Three rewrites

Before: "Implemented new authentication service." After: Engineered OAuth 2.0 authentication service replacing session-cookie auth for 470K active users, dropping login error rate from 2.8% to 0.2%. Why it works: "Engineered" signals you owned the design. User scale plus error-rate improvement gives any reviewer two concrete checkpoints without needing additional context.

Before: "Implemented API rate limiting across services." After: Introduced adaptive rate limiting across 28 internal APIs, protecting 3.4M external requests per day and eliminating an abuse pattern that caused 4 downtime incidents in Q3. Why it works: "Introduced" tells a reader this was new to the org, not a routine task. The API count, request volume, and incident history make it impossible to read as a minor configuration change.

Before: "Implemented automated testing framework." After: Built end-to-end testing framework (Playwright + custom CI hooks) that raised integration coverage from 31% to 84%, catching 17 regressions before they reached staging. Why it works: "Built" is direct and concrete. Before/after coverage numbers make the improvement legible, and the regression count is the payoff line a hiring manager will actually remember.

For context on how these stronger verbs interact with ATS parsing, see our ATS-friendly resume guide.

When "implemented" is genuinely the right word

A few cases where swapping it out would be wrong.

Executing an RFC or compliance specification. When you implemented OIDC, FIPS 140-2, or a regulatory control exactly as written, "implemented" signals faithful execution of a defined standard. The word carries weight here because precision was the job.

Coordinating work you didn't fully own. If your role was stitching together vendor configurations, team sign-offs, and external dependencies, "implemented" honestly describes that coordination without overclaiming engineering ownership you didn't have.

Mirroring the job description. If the target role says "implement scalable solutions across the stack," reflecting that verb in one bullet is a defensible ATS strategy. Just make sure the rest of the bullet has numbers, or the mirroring is wasted.

Why "implemented" is a claim verb — and claims need proof

"Implemented," "delivered," and "achieved" share the same structural flaw: they describe an action without giving a reviewer anything to evaluate. Every engineer in a hiring pool implemented something. The verb becomes noise.

The fix is not only swapping to a stronger synonym. The real move is asking: what changed because of this, and can I express that change as a number? Latency before and after. Error rate before and after. Time saved, dollars saved, requests per second handled at peak. If you cannot produce a metric, a stronger verb alone will not save the bullet — "architected" without a number reads as a fancier claim, not evidence.

The pattern that holds up under a recruiter's six-second scan: strong verb plus specific outcome. "Deployed" paired with a latency delta. "Migrated" paired with a data volume and a maintenance window. "Automated" paired with a ticket-volume reduction. That combination converts a task description into a result, which is what a hiring manager is actually looking for when they read a resume.

Skip the busywork — Sorce applies for you. 40 free swipes/day.

For more: coordinated synonym, facilitated synonym, presented synonym, solved synonym, addressed synonym