Smaczaki: a wholesale website for an importer of dog treats

For an importer of meat treats for dogs I built the wholesale website of the Smaczaki brand: eight pages with a catalog of more than a hundred items, running as a static site on my server and costing the company nothing in software licenses.

The client and the task

IMEX has been importing meat treats for dogs since 2013 and supplies the wholesale market from a warehouse in Poland. The company already owned a domain with working company email on it, but had no working website, so the brand had to be put online from nothing. The job of the site is to bring a wholesale buyer to the point of sending a request for a quote, not to sell through a basket. The client set one condition from the outset: “no WordPress”, meaning no content management system at all, and WordPress in particular.

How this site came about

I divide the work into five stages. After each one I show the result for approval, if the client wants that kind of control over how the work runs. The order of the stages is not accidental, because each one draws on what the previous one settled. Skip one and the missing decisions still have to be made, only at the end, when every correction costs the most.

1. 1

   Discovery

   I start with a conversation about the goods, the buyers, the way they sell and what should happen once someone lands on the site.

   Approval

2. 2

   Personas and journeys

   From the discovery I derive the groups of buyers, along with what each of them is looking for and what they need to know before sending an inquiry.

   Approval

3. 3

   Mockup

   The look is designed before the code, as a mockup of one page.

   Approval

4. 4

   Build

   I write the code using a method called vibe coding: I describe the task in plain language, and it is carried out by a team of AI programs, each with one assigned role.

   Approval

5. 5

   Deployment and search engines

   The site goes onto the server at its final address, and immediately afterwards to Google and Bing, together with a sitemap and traffic measurement.

   Approval

The approval gates are optional. They are switched on by the client, who decides where to stop the work and take a look at it.

1. Discovery. I start with a conversation about the goods, the buyers, the way they sell and what should happen once someone lands on the site. It is really just an interview, the one that turns “we want a website” into a scope of work you can put a number on. On top of that I review the competition and write down what we agreed, so that later there is no argument about it.

2. Personas and user journeys. From the discovery I derive the groups of buyers, along with what each of them is looking for and what they need to know before sending an inquiry. The structure of the site follows from those journeys, meaning the number of pages and what goes on each one. The structure therefore comes from the buyer’s path, not from a ready-made template.

3. Mockup. The look is designed before the code, as a mockup of one page. Changing the layout, the order of the sections or a color takes minutes at this stage and hours once the site is built. It is also the most convenient moment for approval, because the client is looking at the site instead of reading a description of it.

4. Build. Only now does the code get written. I write it using a method called vibe coding: I describe the task in plain language, and it is carried out by a team of AI programs, each with one assigned role. One is responsible for accessibility, another for working correctly at every screen width, from a phone to a widescreen monitor, others for content, for security and for search visibility. None of them reviews its own work, so several pairs of eyes go over the site rather than one.

5. Deployment and submission to search engines. The site goes onto the server at its final address, and immediately afterwards to Google and Bing, together with a sitemap and traffic measurement. Until that moment the search engines have no idea the site exists, so only now can it start earning positions. That day is also the zero point of measurement: from it I count how many pages made it into the search index, which phrases the site appears on and how many visitors arrive through them.

What was built

The site has eight pages: the home page, a catalog overview page with two subpages of products, a page about working together, a page about the company, contact, and a privacy policy. The catalog covers more than a hundred items, and those two subpages divide it by what the hero of the product is, meat or beef hide, because a buyer chooses one and the other for entirely different reasons. The inquiry form runs on its own back end, with no external form service, and ALTCHA defends it against bots: a proof-of-work challenge, where the browser performs a short calculation a person never notices, while a bot sending thousands of submissions pays for it in time. So the buyer does not retype distorted characters or click on tiles of photographs, as with the CAPTCHA everyone knows.

I measure traffic on two levels. Visits are counted by Umami, an open source traffic counter, a lighter counterpart to Google Analytics, installed on the same server as the site. It works without advertising cookies and sends no data outside, so I have a picture of traffic from day one regardless of what a visitor answers on the cookie banner. Alongside it runs Google Analytics 4 (GA4), which only starts once a visitor consents to cookies. Visibility in search is tracked by Google Search Console (GSC) and Bing Webmaster Tools (BWT), and positions on phrases are monitored by Senuto.

How the site is put together

The foundation is Astro, a static site generator (SSG). The whole site is produced once, at build time, and reaches the browser as a finished HTML file instead of being assembled again on every visit. That is where the speed comes from, and it also does away with a database and with plugins, the two most common ways into a company website. There is no content management system to pay a subscription for either, and I keep the site itself on my own server as part of ongoing care. The look rests on custom CSS derived from the brand guidelines rather than on a ready-made template or a framework, and it includes a dark mode.

A brief described in plain language

1. Content and editing
2. Look and responsiveness
3. Accessibility (WCAG)
4. Search visibility
5. Security
6. Review and pre-publication gates

Publication: only code that has passed the checks goes through it.

None of them reviews its own work, so several pairs of eyes go over the site rather than one.

Three things that usually get added at the very end, or never, have been in the code since day one. The first is preparation for search engines, that is SEO (search engine optimization): a sitemap.xml, a robots.txt file, canonical addresses and page descriptions in the title and meta description tags. The second is a form of content that answers generated by artificial intelligence can reach for, as those answers increasingly replace the list of results. That work is called GEO (generative engine optimization), and in Google’s version it means AI Overviews, previously announced as SGE (Search Generative Experience). The third is accessibility compliant with WCAG 2.1 at level AA (Web Content Accessibility Guidelines), meaning keyboard operation, legible contrast and correct behavior with screen readers.

Before every publication the code goes through a set of machine checks, and any finding stops the publication instead of reaching the live site. I deliberately do not write about the details of the server back end, because describing your own defenses is a hint to whoever is testing them.

From order to search engines

A month passed from confirmation of the order on July 20, 2026 to the site going live at its final address on August 19, 2026. The change to the domain settings covered only the entries pointing at the site, and the company email, running on that same domain for years, was left untouched.

The day after launch the site had verified ownership in Google Search Console and a submitted sitemap, which Google fetched within a second and read a complete set of eight addresses from, without a single error and without a warning. The same day the home page came back from the URL inspection tool with the verdict “URL is on Google”. A day later Bing followed, with its own sitemap. All of those readings are written down, which is why later reports show a change against a measured start rather than a general impression that things are better.

What happens next

The work did not end at launch. An English version is being rolled out, and German will follow it, because the company also sells outside Poland. From handover the whole site is covered by ongoing care under a monthly retainer that includes maintenance, further development of the site and search visibility work.

In practice that means the client no longer has to maintain and update the site. Doing it well takes knowledge from three fields at once: how to write content someone will read and then ask for a quote, how to prepare a site for search engines, and how to reach the answers generated by artificial intelligence that increasingly stand between the person asking and the list of results. Without that knowledge a site looks the same a year later as it did on launch day, and means just as much to a search engine. I take that obligation on myself.

The client can also order changes to how the site looks and behaves, not only corrections to the content. We are not limited by a content management system with a fixed set of building blocks, so a change that on the popular platforms ends in the sentence “that cannot be done in this template” is here simply a piece of work to do. The retainer includes a pool of hours for that kind of work, and the rate for each further hour is agreed in advance, so the client knows the cost before ordering a change.

What follows from it

A wholesale website needs neither a content management system nor a software subscription. The cost is the build and running the server, not a monthly license fee. It also does away with a whole category of trouble familiar to owners of sites on the popular platforms: plugin updates, break-ins through them, and the slowdown that grows with every add-on.