The network for creativity
Join 1.25M professional creatives like you
Connect with clients, get discovered, and run your business 100% commission-free
Creatives on Contra have earned over $150M and we are just getting started
Back to feedPost
Fense is an AI-powered platform delivering smart recommendations for real estate and agriculture. By analyzing data and trends, it helps users make informed investment decisions, optimize yields, and identify high-value opportunities. Predictive insights, risk assessment, and actionable advice make Fense AI a practical solution for smarter, data-driven choices.
Appreciate that! 🙌, We put a lot of thought into making the onboarding and recommendation flows feel intuitive while keeping the product grounded in the real-world needs of real estate and agriculture. Glad the earthy palette resonated too 🌱
Absolutely. The recommendation engine is designed to get smarter as more user preferences, property data, location signals, and interaction patterns come in. Over time, that should allow FENSE to move from broad recommendations toward much more personalized land and real-estate...
Predictive/recommendation models like this usually live behind an API rather than on-device, curious how you're handling latency for the map view refreshes as new investment data streams in. Flutter's isolate model helps keep those recommendation recalculations off the UI thread if that's ever a bottleneck.
Yeah, for FENSE, the heavier recommendation logic lives server-side so we’re not tying the map experience to on-device model inference. The client mainly handles visualization and incremental updates as new data comes in. We’re also keeping the data pipeline event-driven so we...
Event-driven over polling makes sense there, keeps the map from re-rendering on every tick. Are you pushing those incremental updates over WebSockets/SSE, or is it more of a poll-and-diff pattern? That choice usually decides how much debouncing you need on the map redraw side.
Worth watching either way: once updates land as individual events, the map redraw cost usually comes from marker diffing rather than the transport itself. Batching events into a 200 to 300ms window and diffing by id before re-render tends to buy more than swapping transport does.
Yeah, that’s a good point. For FENSE, we’re treating the stream and the rendering layer separately, so batching/diffing is definitely something I’d prioritize before changing the transport layer. A short debounce window with ID-based diffs should keep the map responsive while...
Debounce plus ID-based diffing is the right fix, keeps render cost tied to what changed not event volume. Viewport culling stacks well on top of that, skips diff work entirely for markers outside visible bounds. Scales clean even if transport swaps later.
The network for creativity
Join 1.25M professional creatives like you
Connect with clients, get discovered, and run your business 100% commission-free
Creatives on Contra have earned over $150M and we are just getting started
Related posts
I’ve always liked products that solve a very specific problem instead of trying to do everything.
So for the Lovable Challenge, I picked a simple question that event-tent rental businesses hear all the time:
“Can I book a tent for my wedding?”
The problem is… a tent can’t really be booked until you know if the whole event will work.
How many guests?
How much usable space?
Tables? Dance floor? Bar? Stage?
Will the layout actually fit?
Can the crew set it up and pick it up on time?
Usually, the owner has to figure all of that out manually through messages, calls and calendar checking.
So I built TentFit — a spatial booking experience for event tent rentals.
The customer starts by planning the event, then maps out the space and everything they want inside it. TentFit checks the layout and highlights conflicts.
And instead of just saying “doesn’t fit,” it helps solve the problem:
Switch the tent. Move the layout. Remove an element.
Once everything works, TentFit checks the logistics and turns the final setup into a booking.
The goal was simple:
Make the customer’s decision easier, and make the owner’s job easier.
The flow is basically:
FIT → FEASIBLE → BOOKED
I had a lot of fun building the spatial planning part of this one.
X/Twitter post: https://x.com/brjanov/status/2105630218492731501?s=20
Built with @Lovable
#LovableChallenge #ProductDesign #UXDesign #NoCode #SaaS #WebDesign
Nice stuff!
Nike × Champions League Ball Concept
An independent concept exploring what a Champions League ball could look like through Nike’s visual language.
The idea starts with a star containing a Swoosh in the negative space, then extends into a complete ball system using Nike’s existing panel construction.
Designed and animated with Spline, After Effects, and a custom 3D ball tool built for the project.
Unofficial concept. Not affiliated with Nike or UEFA.
This is very well thought of and creative
Real estate dashboards are usually built for data entry. Aurex Living was built for decision-making.
$873,42.39 total revenue. 1,269 completed deals this month. $276K sold, $346K rented. Property cards, agent tracking, map view, average sale value trending +10% - every number a real estate operator actually needs, on one clean white canvas.
