Make (www.makerstage.com) is a digital manufacturing platform company in San Francisco. Get 3D printed or CNC machined parts in record fast lead times through our decentralized network of machines across America & Asia.

Make

Make is a conceptually simple build-system, and it is packaged with major Linux distributions. However, Make should rarely be your build-system of choice when starting a new C++ project. That’s a bold claim, so here’s why… Writing a Large, Correct Makefile is Really Hard The dependency graph of a C++ library is actually quite complex. It must be rebuilt every time a linked object-file changes… But an object-file should be rebuilt every time its translation-unit changes, or the compilation flags change, or if any of its included headers change, or if the compiler changes… You can query this information using the compiler and encode all of this in a Makefile, but it’s going to get really verbose. There’s a high chance that you will miss a dependency. If this happens, then you might have stale artefacts after a change. Cue a clean build! No Sandboxing The lack of sandboxing is the root problem. Make has a dependency graph, but it does not actually enforce it. What this means is that a build-rule can read a file even if it is not declared as a dependency in Make! Caches are Not Portable Make does not allow you to share build artefacts across a network, so everyone on your development team will be performing the same build-steps over and over! Yes, you can use CCache, but that is not general (only compiler calls are cached) and it isn’t provided out-of-the-box. No Language Abstractions are Provided Make’s simplicity is a big strength, but it is also a major weakness. Make doesn’t provide any language-specific abstractions, so you have to write them yourself. This can get very tedious, and the odds of making a mistake are high. This also goes for tests, deployments and so on. You need to build everything yourelf. Timestamps, Not Hashes In determining when to rebuild, Make uses the timestamps of build inputs rather than their hashes. This results in many unnecessary rebuilds when a file has been touched, but has not actually changed. If this happens deep in the dependency tree, then the rebuild will take a long time! So When Should You Use Make? It’s not all bad; Make still has its place as a bootstrapping tool. If you have extreme dependency requirements (for example you are building Linux from source), then you need something simple and self-contained. But for most developers this just isn’t the case. We already fetch Clang, GCC and Visual Studio as prebuilt binaries, so why not download a prebuilt build-system? Since You’re Here… We recently announced , a new tool to optimize your C/C++ build scripts. ! BuildInfer Take a look

Why Not Make?

There are quite a few ways to create new maps and slices in Go. Which one is best? Or perhaps better asked, which one is best in your situation? Let's take a look. Slices varStyle [] literalStyle := [] {}

newStyle := ([] )

makeStyle := ([] , ) var string string new string make string 0 is the idiomatic way to declare an slice. The slice is actually , which means it will be when marshalled to JSON and will succeed nil checks. var varStyle []string empty nil null should probably only be used when the literal is going to , as in . Otherwise prefer literalStyle := []string{} start with values in it literalStyle := []string{"cat", "dog", etc} make() returns a pointer to the slice. Same as . newStyle := new([]string) ptrStyle := &[]string{} Only use if you want a pointer. is the same as the literal style, but is preferred for idiomatic reasons when the . Make() allows the slice to be initialized with a starting length and capacity, which can have good performance implications in some circumstances: makeStyle := make([]string, 0) slice doesn't need non-zero starting values makeStyle := make([]string, len, cap) Maps varStyle [ ] literalStyle = [ ] {}

newStyle := ( [ ] )

makeStyle := ( [ ] ) var map int int map string int new map string int make map string int creates a nil map. Writing (but not reading interestingly enough) will cause a panic. You probably don't want a nil map. var varStyle map[int]int using the literal syntax is just fine, though idiomatically its probably best to use a make function. Developers are more used to seeing a make function and make offers some additional features. literalStyle := map[string]int{} := creates a pointer to a nil map... very often not what you want. newStyle new(map[string]int) ! If you know your space requirements you can optimize for allocation by passing in a size: makeStyle := make(map[string]int) This is probably what you want makeStyle := ( [ ] , ) // Give me a map with room for 10 items before needing to allocate more space make map string int 10 Want to learn more? Check out the Article! How To: Global Constant Maps and Slices Thanks For Reading Follow us on Twitter if you have any questions or comments @q_vault Take game-like coding courses on Qvault Classroom to our Newsletter for more educational articles Subscribe

Go (Golang): Your Cheatsheet On Ways To Create New Maps And Slices

Like many other technical people I learned to code from a young age, I specifically remember learning the likes of HTML, CSS and PHP in order to build out my long imagined dream of running my own successful Club Penguin(rip) blog. I relied solely on the teachings of W3school at the time and while I had a great respect for code and a huge amount of pride every time I printed “Hello World!” on to my screen, it was deeply frustrating. See, I didn’t want to code. I hated the concept of coding. Coding to me was a means to an end, never a passion. I recognised that I wanted something and realised that the only way I could get it was to build it myself and that required code. I hated making anything because I knew I would have to code. The day I became a Maker. Fast forward to 2018 and I’m building a simple crowdsourced based web app and I stumble across a WYSIWYG editor called WebFlow, reeling from past experiences, I was super skeptical but I gave it a shot. Within 2 hours I had a website with a dynamic CMS fully up and running. Then, I came across Airtable and realised I can hook up my apps submission form to the database and low and behold without writing a line of code I built an app that automatically updated records and displayed user inputs on the front end. I was building a thing I quickly started to realise that this was much bigger than I had thought. I didn’t stumble on to one not-so-known app. I had stumbled on to an entire movement. Around that time I also came across another website, Product Hunt (who I ended up working for) and discovered that people were making full apps in a day without code. Products such as: Kith Elements Copy paste reusable elements into your Bubble projects 🚧 Kiths reusable elements help you get started quickly on Bubble. You can easily drag and drop the elements you need into your projects. And customise them however you like. Growth List A crowd-sourced list of growth hacks GrowthList is a crowd-sourced list of actionable, proven Growth hacks sourced by the community MakerPad Free program to learn to build mini-startups without code The concept here is to teach anyone and everyone how to build in minutes and validate with real paying customers via a custom, tailored plan. All products that if I were to build would have required me booting up a code editor and working for hours to build a prototype. All products that, being honest I probably would not have finished. Needless to say, my mind was well and truly blown. That day was important to me as it changed my outlook on making completely.No longer did it feel like an elite club reserved for serious code wranglers but it seemed now that anyone can be a maker, as long as you have an idea, you can make it. I realised anyone can be a Maker The no-code movement is breaking down barriers many would-be Makers have previously faced; the barrier of code. Fuelled by the accessibility of new tools and a growing community of Makers supporting each other, building apps has never been more accessible. Anyone can be a Maker. In less than a day you can build: A crowdsourced, data centric app powered by Airtable A toolkit to run better meetings with Coda A dynamic, CMS driven blog with Webflow An entire Alexa skill using Voiceflow Any assortment of site / app using Sheet2Site A mobile app using Glide These products provide the means for a maker to make. They remove the barrier of code and let Makers focus on what truly matters: the idea. A celebration of Making As I mentioned before I now work for Product Hunt and the Maker community is the bread and butter behind everything we do. My day to day life has changed dramatically just because of products built by Makers launching on Product Hunt and we want to celebrate the genius that is Making. Last year, we launched our first ever Makers Festival where over 2,000 makers from all walks of life, built, tinkered and hacked their way to building a product to showcase to the world. This year we have partnered with for the Makers Festival no-code edition. We want to showcase the true potential of the no-code community and the apps powering it. If you’re passionate about building and you want to discover more about no-code then . Registrations are open until Sunday the 24th of March. We have a prize for every category and if you build with Coda there is a special Grand Prize. Coda sign up here We have a a few themes coupled with collections below to inspire you in your maker journey: Tools for teams Life Hacks Social Impact Health & Wellness Tiny Apps We are in a unique period of time where an idea is the only requirement needed to start making. I truly believe everyone can be a Maker and the community is proving that every day. No code is still in its infancy, but it is a growing movement with some serious potential to shake things up. I’m excited to be part of that. Me now when I go to make something

I hate coding but I love making

Years ago I thought accessibility was for 0.1% of people. Working on apps serving millions of users taught me it’s about way more people, who have to be included when building scalable Angular apps. One of the main goals of us, frontend software engineers, is to make sure the apps we build are accessible to as many people as possible. There are many ways to ensure that, for example having great designs, but also being really focused on how the app works. Testing it in multiple browsers, on multiple resolution, screen orientations and so on. But the term “accessibility” isn’t really about it, but, as Wikipedia says: Web accessibility, or eAccessibility,[1] is the inclusive practice of ensuring there are no barriers that prevent interaction with, or access to, websites on the World Wide Web by people with physical disabilities, situational disabilities, and socio-economic restrictions on bandwidth and speed. When sites are correctly designed, developed and edited, more users have equal access to information and functionality. (source) Web accessibility, or eAccessibility,[1] is the inclusive practice of ensuring there are no barriers that prevent interaction with, or access to, websites on the World Wide Web by people with physical disabilities, situational disabilities, and socio-economic restrictions on bandwidth and speed. When sites are correctly designed, developed and edited, more users have equal access to information and functionality. (source) source source What we can recognize as the user oriented needs for web accessibility can be grouped into multiple categories: visual impairment
motor / mobility
auditory
seizures
cognitive and intellectual visual impairment motor / mobility auditory seizures cognitive and intellectual And we tend to think these issues only affect some minor group. So we apply WCAG rules not always as part of the general process. It’s rather something that is either taken care of to some extend during the whole design and development process, or at some point as a separate task. By the way, my name is Tom Smykowski, I’m an expert in building scalable, enterprise Angular applications and in this series I’ll be teaching you how to do it! By the way, my name is Tom Smykowski, I’m an expert in building scalable, enterprise Angular applications and in this series I’ll be teaching you how to do it! Approaches to accessibility depend on many factors, including legal requirements. But from the people perspective, what can be surprising, that actually accessibility isn’t about a narrow group of people. Just to five some examples. Around 8% of men have what is called congenital red–green color blindness. It means that they can’t to various extend to differentiate some pairs of colors: cyan and gray
yellow and neon green
black and red
red and green cyan and gray yellow and neon green black and red red and green It seems to not affect UI development, until you have a list of alerts and notifications. When alert and notification icons are similar and small, people won’t be able to recognize what is what leading to problems or to considerable inconvenience that will drive them away from your app. And we’re not talking about some minor group. It’s 8% of men. An inaccessible app in that matter can be a blocker for 8% of potential users. If someone came and said, he can increase adoption by around 8%, he would be called a charlatan, but here accessibility itself can do it without any impact on business and marketing processes if initially the app isn’t accessible in that matter. Another set of disorders that affects if people can use apps is motor difficulties. For example essential tremor. It’s a motor neurological disorder causing involuntary, rhythmic shaking of hands that affects almost 1% of global population. People with essential tremor, but also other motor disorders find many difficulties in life, also in the area of digital life where apps that should help them, not always do it. Too small buttons, located too close to each other are only a tip of an iceberg of thigs that can lock out people with disabilities from these areas from your application. Moving fast forward to intellectual and cognitive conditions, just for selective example, we have around 1% of people affected by intellectual disabilities, and separately and not connected, 10% of global population affected by autism spectrum. Complex and overloaded interfaces, ambiguous icons, wording, non consistent navigation, jargon or complex language, no clear feedback, poor readability are just some of elements that affect negatively people with intellectual and cognitive conditions. Again, a quite large proportion of people globally that will find it hard to use your app if it’s not accessible. What’s interesting, especially for MVP driven startups this is essential, because the app shouldn’t only do the one thing that people want, it should also allow them to do it. As you can see, accessibility isn’t only for few people, it’s for a quite large proportion of all people. Around one of three people has a condition that makes using apps difficult. Inaccessible app isn’t just an inconvenience and in highly competitive market it’s a deal-breaker. No one will use an app if they can go to competition that allows them to do just what they need to do despite their various conditions. In terms of scalable Angular apps, it means we should focus on accessibility and treat it as essential process of design and development. I’d say even more, we should sacrifice other design goals if they lower accessibility, because there’s no sense in building pretty things that people can’t use. The goal of architecting scalable Angular apps is to build ones that are widely used, and prepared for global usage horizontally and vertically. In the process terms a good design system and component library are places where accessibility can be provided organisation-wide. But it also requires training and including accessibility in all processes affecting user interface, from requirement phase, through design to implementation and maintained, because everyone involved in these processes has to be aligned to reach for the same goal. That way we don’t build accessibility debt. Compared to technical debt, accessibility debt affects our users every day. Way more people than we think. I’ve prepared a free checklist how to make your Angular app scalable and ready for enterprise demand. If you’re interested, you can get this checklist for free here. I’ve prepared a free checklist how to make your Angular app scalable and ready for enterprise demand. If you’re interested, you can get this checklist for free here. free here free here If you have any questions, ask these in the comment section!

Use This Checklist to Make Your Angular App Scalable

Technology was meant to make our work easier. Hand over the reins to artificial intelligence and let it do all the work for you. But rather than working less, people are busier than ever. We are available 24/7 thanks to emails, Slack notifications, endless meetings, and AI-powered dashboards. Technology makes things far more complex than they need to be. Are we actually more productive, or simply doing more work that resembles productivity? Let’s reimagine the idea of efficiency in the digital age. 🚀 Why Does More Tech Mean More Work? Why Does More Tech Mean More Work? When something like this comes along, there is always this promise of efficiency, but what you get—really—is a compounding of work to do, expectations, and noise. Email was supposed to replace slow communication, but now we all get hundreds of emails a day.
The reports are AI-generated and offer immediate analysis, which means that in this world, companies now expect decisions to come even quicker.
Virtual collaboration tools make working together easier, but they have also created an “always on” culture. Email was supposed to replace slow communication, but now we all get hundreds of emails a day. Email hundreds of emails a day The reports are AI-generated and offer immediate analysis, which means that in this world, companies now expect decisions to come even quicker. The reports immediate analysis decisions to come even quicker Virtual collaboration tools make working together easier, but they have also created an “always on” culture. Virtual collaboration tools easier “always on” culture Rather than reducing workloads, technology tends to increase them—because the more we are able to do, the more we’re assumed to do. A hundred years ago, economist John Maynard Keynes foresaw that technological advances would shorten work hours to a 15-hour workweek. Instead, work has filled every hour to be had. But the problem is not that we don’t have enough productivity tools; rather, we haven’t changed our minds about what work itself is. not productivity tools changed our minds about what work itself is 📊 Productivity: Are We Looking at It Wrong? Productivity: Are We Looking at It Wrong? For decades, companies tracked productivity in hours worked and tasks completed. But in the digital realm, output isn’t always a great indicator of success. Consider two workers: Consider two workers: Worker A answers 100 emails, attends 10 meetings, and generates 20 reports in one day.
Worker B spends the day solving a really complicated problem that improves efficiency for everybody on the team. Worker A answers 100 emails, attends 10 meetings, and generates 20 reports in one day. Worker A Worker B spends the day solving a really complicated problem that improves efficiency for everybody on the team. Worker B Who was more productive? A traditional system would say Worker A, because they completed more tasks. But in fact, Worker B provided more value. Worker A more tasks Worker B provided more value The issue is even more pronounced with remote work. Visibility—who responds immediately to emails, who stays logged in the longest on Slack—seems to be an informal metric on which managers often evaluate employees, rather than actual contribution. informal metric actual contribution Real productivity today is not about doing things; it is about impact. Real productivity today is not about doing things; it is about impact. They want to know, "How many hours did you work?" → Did your work have an impact?
Rather than "how many emails did you send?" → Did that communication lead to improved outcomes?
It’s not "how quickly can you respond?" → Did you not have information? They want to know, "How many hours did you work?" → Did your work have an impact? They want to know, "How many hours did you work?" → Did your work have an impact? Rather than "how many emails did you send?" → Did that communication lead to improved outcomes? Rather than "how many emails did you send?" → Did that communication lead to improved outcomes? It’s not "how quickly can you respond?" → Did you not have information? It’s not "how quickly can you respond?" → Did you not have information? For the future of work, better productivity metrics that reflect real, rather than busy, impact will be needed. future of work productivity metrics real, rather than busy, impact 🤖 AI & Automation: Are They a Shortcut or a Trap? AI & Automation: Are They a Shortcut or a Trap? AI and automation have known benefits in eliminating repetitive work, but they do carry risks: known benefits eliminating repetitive work do carry risks More Data = More Decisions More Data = More Decisions Instant access to analytics can result in decision fatigue, where employees are spending more time analyzing than doing anything with it. Marketing teams always used to make decisions based on a couple of reports a week. Then they had real-time dashboards with thousands of data points—but instead of streamlining the process, it tends to paralysis by analysis instead. Automation 101: Too Much Over-Automation Masks Creativity Automation 101: Too Much Over-Automation Masks Creativity While AI is great at following processes, it has a hard time when faced with outliers or situations where human intuition is required. AI-backed customer support proactively handles 80% of tickets. That works fine—until an unusual case comes along, and human employees discover they no longer have the knowledge or experience to manage it effectively. When utilized properly, automation is incredibly advantageous, but when it comes to AI, it is a slippery slope that will destroy your adaptability if you become overly reliant on it. The Burnout Effect The Burnout Effect Always-on systems put pressure on humans to be always-on as well, which makes deep work and being creative more difficult. A lot of companies will use AI to measure how well their employees are doing, but once workers feel that everything they do is being monitored, they begin optimizing for visibility rather than impact. The purpose of technology is to make work easier, not harder. The purpose of technology is to make work easier, not harder. 💡 The New Energy of AI: Forget Efficiency The New Energy of AI: Forget Efficiency Rather than doing more, faster, we should work smarter. doing more, faster work smarter ✅ Less of the Busy Work, More of the Deep Work Less of the Busy Work, More of the Deep Work Focus is broken by notifications, emails, and instant messages.
If it does, tools are there to magnify, not create, distractions.
Employees should be encouraged to block off time for deep, undistracted work. Focus is broken by notifications, emails, and instant messages. If it does, tools are there to magnify, not create, distractions. Employees should be encouraged to block off time for deep, undistracted work. ✅ Not More Automation, Smarter Automation Not More Automation, Smarter Automation AI ought to automate repetitive steps but invite human intervention when necessary.
Everything should not require absolute complexity.
Over-automation can make simple processes too rigid.
AI is most powerful when enhancing human abilities, rather than replacing them. AI ought to automate repetitive steps but invite human intervention when necessary. Everything should not require absolute complexity. Over-automation can make simple processes too rigid. AI is most powerful when enhancing human abilities, rather than replacing them. ✅ Do Not Count Hours; Measure Outcomes Do Not Count Hours; Measure Outcomes Efficiency doesn’t mean maximizing every hour—it means maximizing value.
Working more doesn’t always lead to working better.
Companies should reward problem solvers, not just busy people. Efficiency doesn’t mean maximizing every hour—it means maximizing value. Working more doesn’t always lead to working better. Companies should reward problem solvers, not just busy people. Many technology leaders say the best employees are the ones who spend time thinking rather than reacting. Deep thinking is an undervalued skill in a world that prioritizes speed. spend time thinking rather than reacting undervalued skill prioritizes speed 📌 Is Human-Centered Tech the Ultimate Productivity Band-Aid? Is Human-Centered Tech the Ultimate Productivity Band-Aid? The next generation of innovation should center on helping people work better instead of just faster. Humans should be served by AI; AI should not replace humans.
Technology must reduce cognitive overload, not increase it.
Work should be measured by impact, not activity. Humans should be served by AI; AI should not replace humans. Technology must reduce cognitive overload, not increase it. Work should be measured by impact, not activity. More companies are also shifting toward a results-oriented work culture—a focus on goals, ingenuity, and long-term strategy rather than short-term output. We need not productivity tools that create new to-do lists, but rather tools that make us do less—but do it better. We don’t need more productivity—we need better ways to work. We don’t need more productivity—we need better ways to work. TL;DR TL;DR Technology was supposed to lighten the burdens of work, but all too often, it adds to them instead.
AI and automation assist in these tasks, but they also drive greater expectations and complexity.
All productivity means is getting things done—and if you succeed, it should also improve life outside of work.
The future of work must become more human, not only tech-driven. Technology was supposed to lighten the burdens of work, but all too often, it adds to them instead. AI and automation assist in these tasks, but they also drive greater expectations and complexity. All productivity means is getting things done—and if you succeed, it should also improve life outside of work. The future of work must become more human, not only tech-driven. Thanks for Reading! Thanks for Reading! What’s your verdict—does technology actually make us more productive, or just busier? Let us know what you think in the comments! actually make us more productive, or just busier?

Technology Was Meant to Make Work Easier, but Has it Just Made us Busier?

What Makes an NFT Project Worthwhile? 

Stop Fighting Data Sync Issues—This Guide Makes MySQL-to-PostgreSQL Transfers Easy

Market makers, also known as liquidity providers, play a significant role in financial markets. For early stage crypto projects, they fill liquidity gaps, and in so doing, help them to navigate through critical development phases. Market makers However, the traditional loan-based market making model has faced significant criticism, with concerns raised over its tendency to become exploitative. In a recent survey with over 400 projects selected across the top 500, top 100 and top 3000 on CoinMarketCap(CMC), this model was criticized for potentially harming projects by draining liquidity and disproportionately benefiting market makers at the expense of projects and investors. traditional loan-based market making model In this interview with Olayimika Oyebanji, Ange Labs’ Head of BD (Oscar) and CFO (JD) provided valuable insights into the emerging retainer-based(profit-sharing) model in market making, contrasting it to the more prevalent loan model. Can you briefly tell us about yourselves and your route to web3? Oscar: To speak about us briefly - our large team includes experts from various niches, including traditional finance and exchanges, professional traders with many years of experience in various companies, top marketers and developers, experts in tokenomics and mathematical models, people with a large investment background. Each of us has many years of experience, both in Web2 and in the Web3 industry. Oscar: Apart from liquidity shortages, what are the other driving factors that lead early-stage crypto projects to seek market-making services? JD: In fact, there are many factors. For example, the vast majority of crypto projects understand that without professional Market Makers it is simply impossible for them to comply with all the rules and conditions of the exchanges, in terms of filling the order books, in terms of spread, especially for large exchanges, where any shortcoming can result in delisting (and everyone knows that getting onto a strong exchange requires a lot of work and a lot of money). JD: No project in its right mind would risk delisting on exchanges; it would be easier for them to hire professionals in this niche for a relatively small fee. Moreover, top Market Makers also help to protect projects as much as possible from all sorts of attacks from arbitrage bots, sniper and sandwich bots. And some teams, like our Ange Labs, also help with connections, with VCs, with Launchpads, with marketing, with fast track listing on exchanges and so on.And there are actually a lot of such points, the easiest way to explain is with the example of a Lawyer in any company - he does his professional work, documents, etc., while the company itself does its work in parallel, development, marketing, etc. Everyone does his own thing, where exactly he is an expert. The same is with Market Makers - they are hired as experts in the field of professional trading. Can you take us through the loan-based market making model? Oscar: As soon as Market Makers realized that this was a real gold mine for them and a way to make money quickly, the Loan Model immediately appeared on the market. The traditional loan-based model is often used by projects who do not have sufficient funding to facilitate trading of their tokens. Oscar: As a rule, it is very beautifully justified and imposed on projects, sometimes beautifully named, for example, "Liquidity Provider", "Investments in the project", "Options Model" and so on and so forth. And projects are happy to fall for this bait. In our philosophy, we categorically refused to use this toxic method, because it kills all projects and the value of the token. What are the criticisms leveled against the loan-based model? JD:If we speak very briefly and understandably for the average person, then this model is notorious for large token dumps, as the market maker is incentivized to drive the token price down in order to repay the loan, by selling the token at the highest price they can.Your project is allegedly invested in, but in reality you do not see these funds, they are completely under the control of MM and here begins the sleight of hand, a competent game for a fall and against the project, because it is very profitable according to Strike Terms. Thus, MM pumps out all the liquidity, all the profit from your project, and the cost of the token rapidly falls down, it is enough to look at hundreds of launches according to this model on Cryptorank or CMC. JD: All these projects now look depressing, despite sometimes top exchanges and Tier-1 VCs, while MM made a lot of money on this. And the worst thing is that then all the complaints come to the project founders from investors, from the community, from exchanges - everyone thinks that the Project or the Project Team is bad and few people think that the real reason was in MM and in the Loan Model. Can you justify your preference for the retainer-based model as an emerging alternative to the existing model? Oscar: As an organization, we use a retainer fees model with adequate monthly fees and % from clear profit. This enables us to achieve good results by profit, by ROI and by reviews. We strongly believe in a win-win for the project, investors, community etc. Oscar: In this model, we are not interested in playing against the project, on the contrary, we are extremely interested in greater profits of the projects, in the development of the token, in order to get our percentage. Our focus is in the long-term trajectory  and achieving  milestones with the project for many years, in contrast to the immediate benefit of the loan model. Having seen the reviews from your previous works, can you explain your modus operandi? Oscar:We have two large departments within the team. One of the departments deals with and helps exclusively with Infrastructure and Fundamental projects. The other department deals exclusively with MEME tokens, since this is also a huge market with completely different operating principles, but we have gathered real experts here and in 2024-2025 helped with the launch of many large projects.As for restrictions, we do not work with companies from the USA and countries where it is prohibited. Well, naturally, we try to select high-quality projects as much as possible, although we certainly can’t get into the heads of the founders. Oscar: Any parting words? Oscar and JD: Make it a point of duty to choose your Market Maker carefully because the fate of your entire project may depend on it. Endeavour to explore the retainer-based(profit-sharing) model as it offers the proven solution to addressing liquidity shortages. Oscar and JD:

MAKE

makerstage.com

1-10 employees

Since 2017

COMPANY RANKING

MAKE

EVERGREEN INDEX #202

Representing this company? Click here to claim and customize this page!

Make WIKI

Apply to get your Tech Company News Page live on HackerNoon.com today!

MAKE

makerstage.com

1-10 employees

Since 2017

COMPANY RANKING

MAKE

EVERGREEN INDEX #202

RELATED COMPANIESRANK

STORIES ABOUT MAKE

Representing this company? Click here to claim and customize this page!

Make WIKI

Apply to get your Tech Company News Page live on HackerNoon.com today!