Building products that scale isn’t just about writing code — it’s about choosing the right stack,...Building products that scale isn’t just about writing code — it’s about choosing the right stack,...
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
Building products that scale isn’t just about writing code — it’s about choosing the right stack, architecture, and engineering practices from day one.
Over the last 6+ years, I’ve worked across mobile, backend, web, and cloud, building production systems using:
• Multi-vendor marketplaces with multiple role-based applications
• Real-time order & GPS tracking platforms
• Payment and subscription systems
• AI-powered applications
• Community & food marketplaces
• Job and hiring platforms
• Donation & transparency platforms
• Logistics and delivery applications
One thing I’ve learned from building these products:
The goal isn’t to make the architecture complicated.
The goal is to make it scalable without making it painful to maintain.
That’s why I enjoy combining Flutter for fast cross-platform product development with Go/Python backend services, PostgreSQL/Firestore, REST APIs, WebSockets, and automated CI/CD.
Currently, I’m focused on building production-ready, scalable systems and helping startups turn ideas into reliable products. 🚀
If you're working on something interesting around Flutter, Golang, AI, SaaS, marketplaces, or mobile platforms, I’d love to connect and exchange ideas.
VentureLens — Venture Lens is an AI agent that turns your raw idea into a good investment using evidence-based sparring.
Instead of putting you through a stale 20-questions test, it asks the one question until it gets your usual answer, makes a short list of recommendations, then combines your data with Qloo’s taste intel and place profiles to create a full, top-to-bottom business brief you can read and download right away as markdown.
Asking one sharp question at a time instead of a 20-question form is the right call. Curious how it decides an answer is good enough to move on, since that's where most validation agents stall or rubber-stamp.
Multi-Model Social Media Agent — Automated Content Workflows
Built by QuantEve Technologies | AI Automation & Full-Stack Engineering
Designed and developed an AI-powered social media workflow that streamlines content research, drafting, evaluation, approval, publishing, and performance analysis.
Rather than relying on a single model for every task, the system uses a multi-model workflow to organize content operations into manageable stages, with persistent state and human review where needed.
Core Capabilities
Content Research: Organizes topics and research inputs into a structured content workflow.
AI-Assisted Drafting: Generates social media content for platforms such as X and LinkedIn.
Multi-Model Processing: Supports model-provider alternatives and fallback handling for more resilient workflows.
Draft Evaluation: Adds an evaluation stage to review and improve content before it moves forward.
Human Approval: Keeps content review separate from publishing so drafts can be checked before external actions.
Workflow Persistence: Uses SQLite-backed queues and stored state to track content as it moves through the system.
Performance Feedback: Organizes publishing analytics and feedback to inform future content decisions.
Engineering Focus
The system brings AI model orchestration, application logic, persistent workflow state, and social media operations together in one maintainable automation pipeline.
Technology Stack
Python / Node.js (depending on the deployed component) · LLM APIs · REST APIs · SQLite · Workflow Automation · Social Platform Integrations
Built by QuantEve Technologies to demonstrate how AI can automate repetitive content operations while keeping the workflow organized, reviewable, and controllable.
Keeping content review separate from publishing, with state in SQLite queues, is a sensible setup. When a model provider fails mid-run and the fallback kicks in, does the queue retry just that stage with the next model, or does the draft restart from research?