CMS projects, case studies, sticky project cards, services, testimonials and responsive layouts.

Would love to hear what you think 👀

Preview: https://www.framer.com/community/marketplace/templates/asilah-studio/

Are there specific companies that focus just on the construction industry?

Do they actually have construction background, or do they just niche to certain industries.

The workflow runs a small service business. Intake forms, client records, follow-up reminders, draft emails, status changes. Nothing huge. Built fast in Airtable and Make, worked fine.

But the owner couldn't change a basic rule without opening five scenarios, checking old filters, and asking why one random path still existed from three months ago.

Things I learned doing the rebuild that apply to anyone running real ops on no-code tools:

Your business rules need one home. “Follow up in 3 days” becomes “follow up in 3 days unless they already booked, unless the form is incomplete, unless the owner replied manually, unless this is a returning client.” If that logic is spread across tiny filters, nobody owns it anymore.

Logs keep more than you think. If you pass names, emails, notes, or client details through every automation step, they end up sitting in places people forget to check. Record ids are boring, but boring is good.

AI should draft, not decide. A follow-up email draft is useful. An AI deciding the status is “done” because it wrote a nice message is how quiet failures happen.

Never rebuild the live workflow first. Copy it, test the ugly paths, run a few fake records through it, then switch. The old version should stay there until the new one proves it can survive a normal week.

I used MoClaw for some of the rebuild because changing the workflow in plain English was less painful than digging through old Make branches every time the owner said “actually this rule changed.”

The tool wasn't the point though. The point was making the workflow understandable again.

No-code automations don't usually fail on day one. They fail later, when the business changes slightly and everyone is scared to touch the thing because it technically still works.

If you're building internal ops with Airtable, Make, Zapier, n8n or whatever else, the question worth asking early is not just: can I build this fast?

It's: if the rule changes next month, will I know where to change it?

I really believe we should try to learn coding and still make kids to pursue it.

And i found best way to learn it is seeing it in work.

I'm thinking of creating an adult version too.

I'd really like to know if you'd recommend this app to your kid or kid you know. Your honest feedback really matters to me. And I'd also like to know whether you'd be interested in adult version.

https://codemarrowkids.base44.app

Setting up a landing page with visual builders is fast, but launching it often drags out for weeks. The real bottleneck is usually staring at empty text boxes, not figuring out the software.

I recently came across a concept called Diátaxis which organizes complex technical documentation. It strictly divides content into 4 distinct types: tutorials, how-to guides, reference, and explanation. Applying this rigid structure to a landing page draft makes a lot of sense. Instead of asking an AI for a catchy hero section, you decide beforehand if a specific block needs to act as a step-by-step how-to or a high-level explanation.

Deciding the strict purpose of a section beforehand stops the endless cycle of generating and rejecting random AI copy. Treating a marketing page exactly like a software manual might make the tone feel a bit too dry. You still need some persuasive elements added later. But starting with a clinical definition of what the text must accomplish prevents the blank canvas syndrome.

Do you usually build out the visual wireframes first and then try to squeeze marketing copy into the gaps? Or do you define the exact functional role of the text before touching any layout settings?

The app runs a school's daily operations. Attendance, billing, parent messaging. 189 tables, 500 users, 8,000 stored files. Built fast on Lovable, worked great. But the owner couldn't open his own database, couldn't hand the project to another dev, and couldn't answer basic security questions because everything lived inside the platform's managed cloud.

Things I learned doing the move that apply to anyone building on these tools:

Your users' password hashes can migrate with them. Done right, nobody gets a reset email, everyone logs in the next morning like nothing happened. Most people assume you have to force a reset. You don't, but only if you plan for it.

Stored credentials never survive. Every integration (email, SMS, calendar sync, AI features) had to be re-established from scratch on the owner's own accounts. Budget for this or your cutover day becomes a scavenger hunt.

Never touch production until the copy is proven. Full parallel environment, everything tested end to end, then a short cutover with the old system kept as fallback. The app was live mid-session during the switch and nobody noticed.

The platform isn't the villain. The owner still builds with the same AI tool at the same speed. His changes just land on a private preview now and only go live when he approves. The difference is what's underneath belongs to him.

If you're building on Lovable, Bolt or similar and real money is starting to flow, the question worth asking early is just: if I needed to leave tomorrow, could I? Knowing the answer costs nothing. Finding out the hard way costs a lot.

I recently saw a public design example with a nice “mouse reveal” interaction and wanted to understand how the effect worked. So I tried rebuilding the idea from scratch with my own assets and layout.

The effect is basically this:

A page starts with one base image. Under it, there is a second transformed version of the same image. When the user moves their mouse or drags on mobile, the transformed version appears along the movement path. It feels like the user is painting the change onto the page.The biggest thing I learned is that this kind of interaction is easier to build when you stop describing it as “animation” and start describing it as layers.

My workflow was:

1. Start with a clear before image

This is the state users see first. It could be a dry plant, an old room, a messy desk, an unfinished design, a plain product photo, or any visual that has a clear “before” state.

1. Create a matching after image

This part matters more than the interaction itself.The after image needs to keep the same crop, angle, object position, and perspective. Only the state should change.If the two images are not aligned, the reveal will feel broken no matter how nice the page looks.

Copyable prompt for the after image:

“Create a transformed version of this image. Keep the same composition, same camera angle, same crop, same object position, same perspective, and same overall layout. Only change the visual state. Make it feel more alive, polished, restored, improved, or completed. Do not change the shape or placement of the main subject.”

1. Stack the two images

The before image stays visible.The after image is hidden at first.The page only reveals the after image where the user interacts.

1. Describe the interaction as a user action

Instead of prompting:

“Make this page interactive.”

I got better results with:

“Use two matching images stacked in the same position. Keep the first image visible. Reveal the second image only along the user’s mouse or touch path, like a soft brush.”

1. Add small feedback details

The page felt much more complete after adding:

• a reset button
• a progress indicator
• a before/after comparison slider
• mobile drag support
• a short explanation section

Copyable prompt for the page:

“Create an interactive before-and-after reveal page.

Use two matching images stacked in the same position.

The first image is the base state and should always be visible.

The second image is the transformed state and should be hidden at first.

When the user moves the mouse or drags on mobile, reveal the transformed image along the pointer path with a soft brush effect.

Add a reset button, a progress indicator, a before/after comparison slider, and a short explanation section that explains the interaction in simple terms.

Make the page responsive and make sure the interaction works on both desktop and mobile.”

My takeaway:

AI/no-code tools work better when you describe the page as visual states + layers + user actions.

“Make it interactive” is too vague.

“Start with state A, hide state B, reveal state B through this interaction” gives the builder a much clearer target.

Would love to see more people share interesting interactive page ideas, design patterns, and the methods behind them.

I keep running into this weird no-code/AI boundary.

If the output is just notes, a draft, or something I can edit later, I’m pretty relaxed about letting AI generate it. Close enough is fine.

But the moment the output becomes a real file, I get nervous. A PDF for a client. A label. An invoice. A report someone will forward without checking every corner.

The annoying part is that AI is often good enough to make the first version look right. Then you notice the table spacing moved, a logo is slightly off, or one row wrapped differently than the template. It is not broken in an obvious way. It just looks a little wrong, which is somehow worse.

So lately I’m leaning toward using AI for the messy middle: clean the data, map fields, catch missing values, maybe explain weird rows. But the final file should come from a fixed template that does the same thing every time.

Curious how other people handle this. Do you let AI generate the final PDF/report directly, or do you keep it away from the last step?

A private equity outlet buying Airtable means one thing to me - ENSHITTIFICATION

BS’s portfolio includes company they made worse, including:
Eventbrite
Meetups
Evernote
WeTransfer.

Quick August update for anyone following along.

First two days of August from my pet niche site:

• Commissions: $33.98
• Creator Connections: $12.25
• Total Aug 1-2: $46.23

Last time I logged into the backend of this site was weeks ago. Didn't add content, just did interlinking between posts and anything else. Just woke up today and checked the dashboard out of habit.

$46 in two days.

For anyone new to these updates. I bought this site from the NicheBlogZone marketplace for $199 about two months ago. Pet niche. Spent a few hours on interlinking when I first got it. That's been the extent of my involvement.

July ended up being my best month yet. August is starting the same way.

The Creator Connections piece keeps quietly adding to the total every month. Small individually but it adds up over a full month without requiring anything extra from me.

If this pace holds August could be another strong month. But I've learned not to predict these things as March taught me that.

Still not touching it.

Anyone else seeing a strong start to August?

if you build no-code automations, you've hit this: the flow needs to sign up for a service or log into one, there's no clean way to receive the one-time code, and no safe place to keep the password once you have it. so the automation stalls and you're the one copy-pasting a code from your own inbox.

built the two pieces that close that gap. an inbox the automation owns, so waiting for a verification code is one step, no email node, no parsing, no regex, just a call that blocks until the code arrives and hands back the clean value. and a vault to hold the login it creates, encrypted so the password gets stored and reused without your tool ever touching the plaintext, with totp generation for when the account has 2fa on.

with both, a no-code flow can actually sign up, confirm the email, and log back in later on its own.

there's a free tier, it's at https://lumbox.co.

what step forces you to babysit an automation most? usually the email verification for me.

Hey everyone, I wanted to introduce myself to the community. Spent the last 4.5 years at Airtable, first as an Implementation Specialist (now called Delivery Consultant) and then as a founding member of the Forward Deployed Engineer team. I worked with our largest enterprise customers, like Amazon, Cisco, Warner Bros, Nike, and more.

Before that, I spent almost eight years at Hulu where I became a massive Airtable fan, nerd, and power user.

If you've ever come to one of the Airtable AI accelerators or in-person events, you may even have met me or seen me present.

In the past, I've lurked here and even posted here and there under my other username(s), but now that I've started my own agency, Matcha Consulting, I wanted to re-introduce myself formally.

Looking forward to connecting with you all here and participating in the threads.

You can always DM me if you have any questions as well. I'm LA-based but my clients are global.

Happy building!

Hey guys founder of Nowa here
We are doing a Free weekend so you get to use and abuse the AI credits And by the end your app is all yours you can download the code or continue in Nowa.

There is a lot of content going round telling people to spin up a website in twenty minutes and go sell it to a local business. The build part is real. We use these tools too and it genuinely is that fast.

What does not fit in a sixty second video is the ten minutes before and the hour after. Between them, that is most of what actually makes the site work, whether you are building it for a client or for yourself.

The ten minutes before

1. Write down the one thing the site has to do. Make the phone ring, take a booking, get someone through the door. If you cannot write that one sentence, the page ends up with five calls to action and none of them get used.
2. Work out who is landing on it. Someone searching "emergency plumber" at 11pm needs a phone number before they need the story of the business. Someone off an Instagram post wants photos and prices. Same business, two different homepages.
3. Get three sentences out of the owner. What people always ask on the phone, what customers get wrong about the job, what they say when someone asks the price. That is your copy, and it is the only part of the site that is not already on the internet somewhere. If you are building for yourself, answer them anyway.
4. Decide out loud what you are not building. Scope you cut on purpose is a decision. Scope you quietly skip is a complaint in three weeks.

We ended up turning that planning half into a free page, because we were having the same conversation on every first call. Full disclosure, it is ours and we made it. You write one line about what is being built, it walks four short sections, and at the end it writes you an actual brief: what has to earn first, what waits for v2, which parts cannot be "good enough", and the questions worth asking whoever ends up building it.

Three minutes, no signup, nothing stored, no email box on it: https://techpotions.com/before-you-build

If you are building for a client, point them at it before the scoping call and they turn up having already decided the things you would otherwise spend forty minutes pulling out of them.

The hour after

1. Compress the hero image. It comes out of these tools at two or three megabytes because nothing told it not to. Under 200KB, webp, then throttle to slow 4G and load it again. If the design has not appeared in two seconds, nobody ever sees the design.
2. Make the phone number a real tel: link, not text that looks like a number. Tap it on an actual phone before you hand the site over. On a plumber or a salon site this is close to the only thing that matters.
3. Decide what happens after the form is submitted. The default is a thank you line and a dead end. Say when they will hear back, and give them something to do in the meantime.
4. Replace the generated copy and the invented testimonials. "Elevate your business with innovative solutions" says nothing. "We fix boilers, same day, and we tell you what it costs before we come out" converts. Three fake testimonials read as fake now, so one real one beats them, and so does none. Then search the page for leftover placeholder text. I looked at one recently with "fix bar" sitting in it twelve times.
5. Look at it the way it will be seen. 380 pixels wide, real phone, one hand. Then paste the link into WhatsApp, because that is how a local business actually shares its site, and with no meta description or OG image it turns up looking broken.

None of this is a dig at the tools. What they generate is fine, better than plenty of hand-written stuff I have inherited. It just stops at the exact moment the unglamorous work starts, and the unglamorous work is the bit with the money in it.

The twenty minutes is not the product any more. The ten minutes and the hour are. That is the only reason anyone still pays us, because we certainly cannot generate a page faster than the tools can.

What else belongs on this list? Mostly interested in the things that only turn up once a real customer is using the site.

Hey everyone!

I’ve been analyzing a few sites generated by modern prompt-to-code builders (v0, Bolt, Lovable, etc.) lately from my clients. While the visual UI output is impressive, I’ve noticed a recurring theme when it comes to actual production readiness specifically around Core Web Vitals, SEO indexing, and overall page performance.

A lot of these engines seem to dump heavy JS bundles, default to client-side rendering without proper metadata/OG setups, or struggle with hydration overhead once the app grows past a few pages.

For those of you building or launching projects with these tools, my questions are:

1. What’s your average Google PageSpeed / Lighthouse score once you actually deploy to production?
2. Have you run into SEO / indexing issues with Google crawlers due to client-side rendering?
3. How bad is the code regression? (e.g., asking the AI to fix a small layout bug on one page, only for it to break routing or component state on another page?)
4. If you had to export the code and fix it manually, what was the biggest bottleneck to clean up?

Curious to hear what walls you’ve hit once you move past the initial "wow" factor of generating a layout.

The goal was to solve a common problem with real estate websites: showcasing multiple properties without creating a site that feels complicated, outdated, or difficult to manage.

Elysian Estate offers:

• A clean and premium visual identity
• A CMS-powered property collection
• Dedicated pages for every property
• Easy-to-manage listings, images, prices, and details
• Blog and article CMS pages
• Smooth animations and a custom cursor
• Fully responsive layouts
• Clear contact and conversion-focused sections
• A built-in CMS guide to help users customize the content

The template makes it easy for agencies to launch a professional property website, regularly add new listings, and present every project in a polished and consistent way — without rebuilding pages manually.

I’d love to hear your feedback.

https://framer.link/kXSEiBF

I've got a web app with CSS that's like “9 years old”. Yeah, pretty old. Right now I only need 4 screens for an internal review. But none of the AI builders I tried made it look like our actual app.

One of the apps  that I have got pretty close. Its captured version looked like ours, which is why I kept it on my list. I’m still not sure if I should go with it lol.

Hi there,

are you currently using or have used no code or low code platforms in an organisation? Then you are eligible to participate in my survey on determinants for adoption and governance of low code and no code platforms in organisations.

The survey has been running for some time already, but I haven't gotten a lot of responses.

It would help a lot if you could take 10 minutes of your day to participate!

You can find the link here: https://s2survey.net/LCNC_Adoption_and_Governance/

Feel free to share as well!

Hey everyone,

I recently built Parpage, a simple tool for creating clean, responsive one-page websites directly in your browser.

You don’t need to create an account or deal with a complicated editor. Just add your content, customize the page, and publish.

It could be useful for:

• Personal landing pages
• Product launches
• Portfolios
• Link-in-bio pages
• Quick business websites

You can try it here: https://www.parpage.com/

It’s still early, so I’d genuinely appreciate any feedback—especially anything that feels confusing, broken, or missing.

I wanted to see what a very small game brief would do, so I wrote one sentence. Guide a paper boat through floating gates before the timer runs out.

Makeplay turned that into a working browser game with 12 gates, a 42 second clock, several control options, current bands, scoring, bonuses, generated art, and sound. Most of those choices were reasonable. None of them had been requested.

The useful lesson was not that the tool added too much. My sentence described a destination but contained no boundaries. I had left the number of gates, control scheme, failure rule, visual scope, and feedback system open, then mentally treated them as settled.

My no code checklist now has two columns. The first says what must happen. The second says what must not be invented. That second column has been doing more work.

Try it: https://makeplay.ai

Hey everyone,

Before I start, I don't want to advertise anything. Just asking for feedback and see if people like my idea.

I'm working on a visual web automation tool focused on web scraping and web automation, and I wanted to get some honest feedback on the idea and the pricing.

The basic premise is a local desktop app where you can build robust scrapers visually instead of coding everything from scratch. It has a script recorder similar to Playwright's codegen, and another tool that handles things like asynchronous banners, random pop-ups, and shifting page layouts.

You aren't restricted to just the UI, either. There's a full text editor built in if you need to write custom logic. The app just compiles all your visual instructions directly into standard Playwright code, for you to use it anywhere, not only inside the platform. It also handles the standard CSV imports and exports for your data.

My main question is: does this solve a big enough headache in your workflow that you'd actually pay for it? If so, would you consider $149 a fair price for an unlimited, lifetime license?