7is Operations consulting

A Hebrew-only site, rebuilt and restyled, bilingual in one week.

Role
Full rebuild: theme, design system, bilingual layer, translation, deployment
Engagement
23 - 30 Jul 2026

7is is an Israeli operations-consulting firm, founded in 2010, advising senior management in banking, insurance, retail, automotive, telecom and healthcare. Its clients are the kind of organizations that run in two languages. Its website ran in one.

The site was Hebrew-only, on a theme called sevenis that had picked up a new library every year or two since it was built: Foundation 6, gulp and SCSS, jQuery, Font Awesome, animate.css, motion-ui and wow.js. Every page’s copy lived in a single undifferentiated block of the WordPress editor.

I rebuilt it. New theme on Tailwind v4, a facelift rather than a ground-up redesign, a second language, and the page content moved into labelled fields. First commit 23 July, last on 30 July, working with Claude Code throughout. It is now live at 7-is.com in both Hebrew and English.

Before7-is.com (old build)
Before
After7-is.com (live)
After
The homepage, whole page, both builds scrolling together. The hero photograph survives; almost nothing below it does.

What changed for the firm

The site speaks English now, which is the whole reason the project happened. Everything else followed from it. You cannot bolt a second language onto a stylesheet that only knows how to lay out right to left, so the language requirement forced the theme rebuild, and the rebuild in turn made room for a facelift that was already overdue.

The site also looks like a firm that advises banks again. The old design had drifted into a collection of pages that each solved their own layout problem in their own way, and what replaced it is a system those pages draw from.

The pages are a lot lighter. There are real measurements further down rather than me just saying so.

The marketing team can edit it now. The About and Careers pages were a single block of HTML that the template sliced up by guessing at where the headings fell.

Each section is now its own labelled field, which is the editing experience a page builder promises without the weight one brings.

Before and after, in numbers

Before is the build 7-is.com served until launch, measured in late July. After is the live build today. The JavaScript row is the one that barely moved: the legacy bundle still ships.

Languages

Hebrew only

Hebrew + English

Polylang Pro, 23 paired items

Theme CSS

rtl.css 1,121.5 KB + main.css 1,121.2 KB

tailwind.css 68.1 KB

one file, no RTL build

Theme JS

main.js 1,902.7 KB, unminified

720.6 KB on disk, 89.1 KB over the wire

legacy bundle still ships

LCP, throttled mobile

not measured

805 ms

CLS 0.00, Slow 4G + 4x CPU

Files in theme

409

294

250 files changed

Font files in repo

156

8

2 variable woff2

Rebuilding the theme

The old theme was based on a starter called podium. Nothing about it was unusual for its era, and that was the problem: eight years of defaults, each one reasonable on its own, that added up to a codebase nobody wanted to touch.

The removal ran in explicit numbered phases, each its own commit, so that any phase could be reverted without unpicking the others.

  1. Phase 1 removed dead code.
  2. Phase 2 dropped Font Awesome, animate.css, motion-ui and wow.js.
  3. Phase 3 laid the Tailwind v4 foundation.
  4. Phase 4 removed Foundation entirely.

Icons became inline SVG in inc/icons.php, which removed a webfont and a render-blocking request. The homepage carousel moved from slick to Splide and now loads only on the front page instead of on every page.

The theme went from 409 files to 294. Across the project: 250 files changed, 17,577 insertions, 59,651 deletions.

  • 106 commits
  • 250 files changed
  • +17,577 insertions
  • -59,651 deletions

Deletions outnumber insertions roughly three to one, which is the honest shape of this kind of work. Most of it was removal.

A design system in 53 custom properties

The old stylesheet expressed its design decisions as SCSS variables compiled away at build time, plus a lot of values typed directly into rules. You could not inspect a colour in the browser and find out what it was called.

The new build states the system as 53 CSS custom properties in src/tailwind.css: colour, type scale, spacing and containers. The type scale carries its reasoning inline.

--text-base: 1.125rem;  /* 18 - body copy */
--text-lg:   1.25rem;   /* 20 - lead paragraphs, card text */
--text-3xl:  2.5rem;    /* 40 - section display */
--text-5xl:  3.75rem;   /* 60 - homepage hero (was 55) */

--color-brand: #f5771c;      /* the accent - CTAs, borders, active nav */
--color-brand-dark: #d55f09; /* button hover (was SCSS darken 10%) */

That was SCSS darken 10% comment is the point of the exercise. The old hover colour existed only as a function call; now it is a value with a name, and the next person does not have to run a build to find out what it is.

The 3 MB that nobody had noticed

One finding from the audit deserves recording, because it cost nothing to fix and had been live for years.

The theme’s inc/enqueue-scripts.php listed the production domain 7-is.com in its $dev_domains array. WP_ENV therefore resolved to development in production, and the live site served unminified development assets to real visitors: two stylesheets of 1,121.5 KB and 1,121.2 KB, and a 1,902.7 KB JavaScript bundle.

Over 3 MB of theme assets, unminified, on every uncached page load. Not a slow server and not heavy images. One domain in one array.

The two stylesheets are now a single tailwind.css of 68.1 KB, with no RTL build. How that happened is the next section.

The new look

Most surfaces were restyled. The parts worth describing are the ones where a decision that had been taken over and over, differently each time, finally became a single component.

Every inner page now opens with a shared banner, sevenis_page_hero(). Before, a page began with a bare photo band and then, further down and visually disconnected from it, a title. The banner puts them together and gives every section of the site the same entry.

The house gesture is a “section head”: an orange rule and a concentric-rings mark, used consistently across sections so that the eye learns the site’s structure. Two button treatments, “Wipe” and “Hairline”, were adopted from a design study and applied everywhere instead of being reinvented page by page.

The header was rebuilt dark with a smaller mobile bar. The footer became a closing call to action, link columns and a contact block, instead of a dumping ground.

BeforeAfterBeforeAfter
The services page. The change that matters is not the palette: it is that every band now comes from the same set of components instead of solving its own layout.

Typography got a single scale, all headings set to 1.3 line-height, and a variable woff2 with a metric-matched local fallback declared as local("Arial") and friends, so that swapping in the web font does not shift the layout. The repo went from 156 font files to 8.

The scroll-reveal animation survived, much subtler than the wow.js version it replaced.

Hebrew and English

The site had no English locale at all. Adding one was the largest single piece of work and the reason for most of the rest.

The bilingual plumbing

Polylang Pro, with Hebrew (he_IL, RTL) as the default language and English (en_US, LTR) second. Menus, Contact Form 7 forms, ACF field values and a header language switcher all follow the active language.

I kept the Hebrew slugs on the English URLs, so an English page sits at a path like /en/אודות/. That looks odd written down, and it means the two languages stay paired without maintaining a second slug scheme that can silently drift out of sync.

Theme-level strings are authored bilingually inline through a small helper, sevenis_txt($he, $en), which resolves against pll_current_language() and falls back to Hebrew. There are 44 call sites.

The alternative, .po catalogues, was rejected because the existing code was already doing the same job with ternaries scattered through the templates. The helper states the condition once.

Hebrew7-is.com
Hebrew (RTL)
English7-is.com/en/
English (LTR)
The same homepage in both languages. Both are the new build: the old site had no English locale, so there is no English 'before' to compare against.

Logical properties instead of an RTL build

This is the most transferable thing in the project.

The old build shipped a separate rtl.css, a full 1,121.5 KB mirror of the main stylesheet, because the main stylesheet was written in physical directions and a mirror was the only way to flip it. The new build has no RTL stylesheet and no is_rtl() branch anywhere.

Direction comes from the dir attribute on <html> plus CSS logical properties: padding-inline-start rather than padding-left, margin-block-end rather than margin-bottom. The browser resolves them per direction. Only genuinely physical things carry a [dir="rtl"] rule, and there are very few: a background-position crop, a fixed-position dock.

New to these? I wrote a separate guide to CSS logical properties, with the full list and what each physical property maps to.

A bilingual site is one stylesheet, not two. That second stylesheet was never a requirement of bilingualism. It was a symptom of physical CSS properties.

Translating the content

Plumbing is not translation. The content had to be written.

Content type Hebrew English
Pages 7 7
Service and insight articles 17 16
Blog posts 3 0

23 of the 27 Hebrew items have an English counterpart wired as a Polylang translation pair. Those four gaps are deliberate. The three blog posts are dated Hebrew-market announcements with no English audience, and one service article was held back by the client.

Contact Form 7 runs as two separate forms, one per language, instead of a single form juggling conditional strings.

Both are protected by Cloudflare Turnstile, which replaced a reCAPTCHA badge that sat awkwardly in the new footer and collected data the firm had no reason to collect. I wrote that setup up separately in configuring Cloudflare Turnstile with Contact Form 7.

7-is.com/en/
Contact page, English
The English contact page. The form is a separate Contact Form 7 instance, not a translation of the Hebrew one, with Turnstile in place of reCAPTCHA.

Performance, measured

The original brief for this write-up carried a caveat that no performance measurements had been taken. Now that the site is live, they have.

The site runs WP Rocket on a LiteSpeed host. WP Rocket does the page caching, minifies CSS and JavaScript, and defers five scripts on the homepage. My full settings walkthrough is in the WP Rocket guide.

What a visitor to the homepage actually downloads today, measured over the wire with compression on:

Asset On disk Minified Over the wire
tailwind.css 68.1 KB 68.7 KB 13.6 KB
main.js (legacy bundle) 720.6 KB 409.6 KB 89.1 KB
splide.min.js 29.1 KB 29.1 KB 12.6 KB

Roughly 115 KB of theme CSS and JavaScript over the wire, against a build that used to serve over 3 MB uncompressed.

On a throttled mobile profile, Slow 4G with a 4x CPU slowdown, the homepage records LCP 805 ms and CLS 0.00.

The layout-shift figure is the one I am most pleased with. It is the direct payoff of the metric-matched font fallback: the web font arrives and nothing moves.

These are lab numbers from a throttled trace, not field data. The site has not been live long enough to appear in the Chrome UX Report, so there is no real-user measurement yet.

Page content out of blobs and into fields

The About and Careers pages kept all their copy in a single post_content field. The template cut it into visual bands by splitting on <h2> headings, which worked, and which also made the page structure invisible to whoever was editing it. Delete a heading and two bands silently merged. The team grid appeared only because a [sevenis_team] shortcode happened to sit in the right paragraph.

Each band is now a labelled ACF tab and the team grid is a checkbox.

A helper falls back to the old <h2> split when the fields are empty, so an unfilled page, a fresh translation or a duplicate, still renders instead of collapsing to a banner and nothing.

One trap worth passing on: ACF’s hide_on_screen setting does not hide the content editor under the block editor. It only reaches the classic editor. The editor had to be removed with remove_post_type_support(), scoped to the single page being edited.

BeforeAfterBeforeAfter
The About page. It was one undifferentiated column of text under a photo band; it is now a banner and a set of alternating bands, each one an editable field instead of a paragraph that happens to sit in the right place.

Deployment

A GitHub Actions workflow builds the theme and rsyncs it to Cloudways on push. Two details in it exist because of specific hazards.

The rsync refuses to deploy anywhere except the 7is application. Several projects share one Cloudways server behind opaque directory names like erhxryjtbb and zaqhvpuxze, which are trivially easy to confuse and catastrophic to confuse. The staging host key is pinned, not scanned.

Cache purging runs innermost-first. Breeze holds rendered HTML on disk, so purging Varnish first only refills it from Breeze’s stale copy. That took three successive commits to find and fix.

Staging carries its own search-engine guards keyed to the request host and not to a WordPress option, because staging is refreshed by importing the production database, which overwrites any option-based setting including core’s own “Discourage search engines” checkbox.

How I worked

One week is quick for a rebuild this size, and I want to be precise about why, because the answer is not that I type fast.

I ran the project with Claude Code. The honest version of that claim is narrower than the marketing version: the AI did not design the site, and it did not decide anything that mattered.

What it changed was the cost of working in small, individually verified steps. A rebuild touching 250 files can be run as a hundred separate changes, each one diffed against a known-good baseline, once the mechanical cost of checking a change properly falls close to zero.

That is where the speed came from. None of the habits below would be worth dropping on a project with no AI anywhere near it, which is rather the point.

1. The old theme was committed first, untouched

The first commit is a snapshot of the theme exactly as it ran on 7-is.com. Not cleaned up, not reformatted. Everything after that could be diffed against precisely what production was serving, which is what made the rest of the work checkable instead of merely careful.

2. Non-trivial work got a written spec first

Two specs sit in the repo, one for the homepage team section and one for the ACF content move. Each states the problem, the field structure, the fallback behaviour, how the result would be verified, and an explicit list of what was deliberately out of scope.

The spec is what makes an AI-assisted change reviewable. An agent will cheerfully build whatever you describe.

So the spec is where you find out that what you described is not what you wanted, while that is still cheap to discover. The non-goals section earned its place more than once.

3. A commit per change, with the reason in the message

106 commits, with messages that explain why, not what. This one records a bug that never happened:

Keyed to the band’s CONTENT rather than to its index, so reordering the sections cannot strand the rings behind the portraits.

Whoever reorders those sections in the CMS a year from now will not know how close that was, which is exactly why the message says it.

Comments in the code do the same job for rejected alternatives: why a border was not used instead of text-decoration, why a host test beats a WordPress option.

4. Refactors were proven neutral, not assumed neutral

Anything meant to be visually neutral had to be shown to be. I captured the rendered HTML of every affected URL before the change, normalised away per-request noise such as Contact Form 7 nonces and asset cachebusters, then diffed after. The ACF content migration was accepted only once three of the four pages came back byte-identical and the fourth differed solely in an intentional typographic change.

“It looks the same” was never the standard.

5. Every change was checked in both languages

On a bilingual site, “it works” is an incomplete sentence until you say which locale. Several commits exist purely because a fix in Hebrew broke English, or because a bilingual sweep found an untranslated string.

Type and spacing fixes were verified by reading computed styles at 390px and 1440px in headless Chrome, not by eyeballing a screenshot.

That is how one reported bug turned out to be three. A heading was flagged as too large in one section, and querying every heading on the page found the identical defect in two others.

What it adds up to

A Hebrew-only consulting site is now bilingual, on a theme that was rebuilt rather than patched, with a design system it did not previously have and its page content in labelled fields instead of one editor blob.

The numbers that matter: 23 paired translations across two languages, 409 theme files down to 294, roughly 115 KB of CSS and JavaScript over the wire, and a homepage that paints its largest element in 805 ms on a throttled phone without shifting the layout.

One week of work, most of it in three days, and the parts that are not finished are written down above rather than left for someone to discover.

Need a rebuild like this?

Bilingual WordPress builds, RTL and LTR from one stylesheet, and asset weight that is measured rather than estimated.