Simple output. Thoughtful structure.
NDLSK B2B Leads began with a strict output requirement: clean HTML and CSS files, no CMS, no framework, and no JavaScript dependency. The real work was meeting that constraint while making the site comfortable to update, fast to load, and easier to maintain later.
- Static HTML
- SCSS
- Gulp
- CSS-only interactions
- Responsive design
Overview
A static website is easy until the second edit.
The project needed to deliver strict HTML and CSS files for use inside a separate service. A CMS, builder, framework, or JavaScript layer was not an option: the pages had to stay light, portable, and predictable in the client's environment.
Taking that constraint literally would have created a different problem. The site could be delivered as copied static files, but every later content change would become more fragile: headers, footers, pricing blocks, FAQ groups, and repeated sections would all have to be edited by hand in several places.
The first version may look clean. The third edit is where the problem shows up: one page gets updated, another page is forgotten, and the site quietly stops agreeing with itself.
The solution was to keep the delivery exactly as simple as required, but make the source much more comfortable to work with. Reusable sections could be changed once and assembled everywhere. SCSS could stay readable in source and become minified CSS in production. Images could be added normally and prepared by the build instead of becoming another manual export task.
Challenge
The challenge was clarity, not decoration.
The offer had several buyer paths: weekly lead reports, plan comparison, full-service support, custom lead lists, testimonials, and FAQs. Each path needed to feel simple for a buyer while staying consistent for the person maintaining the site.
The client asked for
plain static output The source structure was designed around that requirement: reusable sections, readable SCSS, minified production CSS, optimized media, and CSS-only interactions where the interface needed them.Solution
Respect the output. Improve the source.
The implementation stayed faithful to the required output. Visitors and the client's service receive plain HTML and CSS. Behind that, pages are assembled from reusable sections, readable styles are compiled into minified CSS, and media is optimized for lighter final files.
In practice, this means a navigation change is made once. A pricing pattern is edited in one place. A FAQ section can be reused without being copied like a fragile paragraph in a document. And when a page does not use a section, it does not need to carry that section's styles either.
Reusable source sections
Header, footer, pricing blocks, FAQs, proof sections, and content bands could be assembled without copying the same markup by hand.
Section-level styles
Each page could include only the styles for the sections it used, keeping the source easier to change and the final CSS closer to the actual page.
Optimized media
Source images could be dropped in normally, while the build prepared lighter formats and cleaner delivery for the final site.
Clean production output
The final site stayed as plain HTML and minified CSS that could be handed over and used inside the client's service without a runtime or extra tooling.
Page flow
One site, several kinds of doubt.
The public site is not just a landing page with a few extra links. It is a sequence. Each page answers a different question a buyer may have before they are ready to act.
Someone new starts with the homepage. Someone comparing options moves to pricing. Someone with a narrow target market needs custom leads. Someone who wants the whole operation handled needs full service. Someone skeptical checks testimonials and FAQs. The site gives each of those readers a door.
Homepage
The first screen says what is being sold, who it helps, and what to do next. Below it, the page explains the offer through proof, process, data, and reasons to act.
Open pageHow it works
A simple three-step explanation turns the service into something a buyer can picture: choose a plan, receive leads, start outreach.
Open pagePricing
Plan comparison gets its own room. Growth, Scale, Free, and Full Service options can be read without compressing every detail into the homepage.
Open pageCustom leads
Some buyers do not need a subscription. They need one researched list for one exact ICP. This page gives that use case its own path.
Open pageFull service
A higher-touch offer needs a different promise: managed campaigns, qualified leads, account support, reporting, and custom pricing.
Open pageTestimonials
Social proof is collected into a dedicated page, then reused across the site where trust is needed without interrupting the main explanation.
Open pageFAQs
Objections are treated as part of the product. Data quality, decision makers, competition, discounts, deliverability, and cancellation all get a place.
Open pageContact
The final step is not a decorative form. It gives different contact routes depending on whether the visitor wants direct context, hiring, or a professional connection.
Open pageWeekly reports, verified contacts, and a focused entry point.
More leads, decision makers, priority support, and database access.
A separate path for managed outreach and tailored requirements.
Information design
Every page carries one job.
The homepage does not try to be everything. It introduces the offer and sends the reader onward. Pricing handles comparison. Custom Leads handles one-off ICP research. Full Service handles managed outreach. Testimonials handle trust. FAQs handle objections.
This is where the static source structure matters. These pages share navigation, footer links, CTAs, repeated proof blocks, and familiar section patterns. They should feel like one product, not a folder of unrelated HTML files.
Implementation
Clean files at the edge. Careful structure underneath.
The project uses a build step where it helps, and avoids weight where it does not. Gulp assembles reusable source sections, SCSS stays organized around the sections each page actually uses before compiling into minified CSS, and media optimization prepares lighter final assets. The delivered result stays strict HTML and CSS.
Nothing about the final site asks the client's service to be clever. The extra structure stays in the workshop: it reduces repeated work, removes the need to hand-minify CSS after every change, handles media preparation, and keeps the finished files dependable.
- Final delivery: HTML/CSS only
- CSS-only interactions
- Gulp page assembly
- Reusable partials
- Section-level styles
- Media optimization
What this shows
The brief defines the constraint. Engineering shapes the system.
A good brief brings the goal, the context, the limits, and the result that needs to be delivered. Engineering starts by taking those limits seriously, then thinking a few steps ahead: who will update the site, where repeated content can drift, how styles will be prepared, and how media will stay light without turning every change into a chore.
In this project, the required result was plain HTML and CSS. A literal execution could have produced that by copying repeated sections across several pages and manually preparing assets after each edit. It would satisfy the request, but it would also make the site harder to change later.
The better answer was not to fight the constraint. It was to keep the delivered files exactly as simple as needed while designing a source structure that made the work easier to maintain. That is the difference between completing a task and engineering a result.